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Parallel Processing 


with the Inmos Transputer from Computer System Architects 


APPLICATIONS 


• High-Performance • Cost Effective 

For computationally intensive applications such as simulation, 
signal processing and graphics rendering. For image processing 
and pattern recognition. For distributed databases. For real-time 
applications like transaction processing, data acquisition and robo¬ 
tics. Using from 1 to 64 (or more) processors. Incrementally 
expandable and field upgradable. 

• Acceleration for PC’s and Workstations 

For applications requiring a large, flat, memory address space. For applications which may benefit from incrementally scalable 
performance by simply adding processors. Put from 1 to 16 processors (with up to 32MB) inside the PC or use just 1 slot 
to escape to an external chassis. One transputer is up to 3 times faster than a Deskpro 386/25 with 80387! 


HARDWARE 



Compute Nodes 

Processors: Inmos T425 or T800 32-bit transputers. Up to 
12.5 MIPS and 1.25 64-bit MFLOPS (with no vector pipelining 
required). Two on-chip timers facilitate real-time applications. 

Hardware scheduler supports multiple processes on each processor. 

Links: Each processor has 4 bidirectional serial communication 
links, providing data transfer between nodes at up to 9MB/sec 
(overlapped with computation). Links are differentially buffered 
and user-configurable, allowing multi-cabinet systems. Memory: Each node has 4KB of 50 nsec SRAM and up to 8MB of 
local DRAM. Size: 1 to 4 nodes per board, with up to 20 boards per cabinet. Boards also fit in PC’s and AT’s. 

Cost: Compute nodes range in price from $900 (a 20 MHz T425 with 256KB) to $5,995 (a 25MHz T800 with 8MB). 



CSA PART6A: Four T800 transputers with 1 MByte RAM per processor 


• High-Speed Interfaces and Accessories 

Interfaces for PC and AT hosts. Also for Apollo and SUN-386i workstations which use the AT bus. For hosts and peripherals 
using the VME bus, including the Apollo-10000 and SUN-3 and -4. A SCSI interface is even available, allowing direct 
connection of disks and other SCSI peripherals. Also for hosts with a SCSI port, like the Macintosh. 

Accessories include a transputer-based color graphics controller, a 32 x 32 link switch (allowing programmable reconfig 
uration of link connections), and a proto-board (with 16-bit T222 processor and SRAM/EPROM) facilitating custom data 
acquisition and real-time control. 


SOFTWARE 


• ANSI Standard C • FORTRAN 77 • Modula 2 • Occam 2 • Pascal 


Compilers come with transputer network loaders, concurrency and 
message passing libraries, and host server programs for DOS or 
UNIX. Prices start at $400 (a complete C development system). 

• Operating Environments and Libraries 

Express from ParaSoft and Helios from Perihelion. Debuggers. 
Math libraries fromTopexpress. Graphics libraries. And more. 


Computer System Architects 

950 N. University Avenue 
Provo, Utah 84604 
(801) 374-2300 
FAX: 374-2306 


Call, write or FAX for more information. 



Bringing the Power of the Transputer to Science and Industry 
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NEW FOR NETWORK ANALYSTS 



NETWORK II.5 now predicts performance of 
computer-communication nets including LAN’s 


Free trial and, if you act now, free training 


N etwork 11.5 uses 

simulation to predict your 
network performance. You simply 
describe your network and work¬ 
load. 

Animated simulation follows im- 
mediately-no programming delays. 

Easy-to-understand results 

You get an animated picture of 
your network. System bottlenecks 
and changing levels of utilization 
are apparent. 

You can simulate some portions 
of the network at a detailed level 
and others at a coarser level. 

Your reports show response 
times, messages delivered, messages 
lost, device utilization, and queue¬ 
ing statistics. 

Computers with NETWORK H.5 

NETWORK II.5 is available for 
most PC’s, Workstations, and 
Mainframes. 


Your network simulated 

You can analyze any LAN, 
embedded computer system, or 
other computer-communication net¬ 
work. Industry standard protocols 
such as FDDI and IEEE Standard 
802.X are built-in. Others can be 
modeled. 

You can easily study the effect of 
changing network parameters or 
even network protocols. 

Seeing your network animated in¬ 
creases everyone’s understanding of 
its operation and builds confidence 
in your results. 

Free trial information 

The free trial contains everything 
you need to try NETWORK II.5® 
on your computer. For a limited 
time we also include free training 
-no cost, no obligation. 

Call Paul Gorman at (619) 
457-9681, Fax (619) 457-1184. In 
Europe, call Nigel McNamara on 
(01) 332-0122, Fax (01) 332-0273. In 
Canada, call Francis Lobo at (613) 
747-7467, Fax (613) 747-2224. 


Free trial offer 

See for yourself how NETWORK 11.5 
quickly answers network performance 
questions. 

Limited offer-Act now for free training. 

□ Send info on your University Offer. 
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Return to: ieee Ci 

CACI Products Company 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Call Paul Gorman at (619) 457-9681. 

Fax (619) 457-1184. 

In Europe: 

CACI Products Division 
Palm Ct., 4 Heron Square 
Richmond-Upon-Thames 
Surrey TW9 1EW, UK 

Call Nigel McNamara on (01) 332-0122. 
Fax (01) 332-0273. 

In Canada: 

CACI Products Company 
1545 Carling Ave. 

Ottawa, Ontario, K1Z 8P9 

Call Francis Lobo at (613) 747-7467. 

Fax (613) 747-2224. 

NETWORK 11.5 is a registered trademark and : 
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11 A Noninvasive Architecture to Monitor Real-Time 
Distributed Systems 

Jeffrey J.P. Tsai, Kwang-Ya Fang, and Horng-Yuan Chen 

Equipped with a programmable qualification control unit for observing system states of a target node, this monitoring 
system can support performance evaluation, testing, and debugging of real-time distributed computing systems. 


26 A Graphical Data Manipulation Language for an 
Extended Entity-Relationship Model 

Bogdan Czejdo, Ramez Elmasri, Marek Rusinkiewicz, and David W. Embley 
Using graphical interfaces to formulate queries and updates makes it easier to interact with database systems for both 
novice and experienced users. 

38 An Expert-System Shell Using Structured Knowledge 

K.S. Leung and M.H. Wong 

Two expert systems built with this prototype shell have demonstrated its power and flexibility. It mixes declarative and 
procedural knowledge, overcoming a major problem of conventional shells. 

50 The Object-Oriented Structured Design Notation for 
Software Design Representation 

Anthony I. Wasserman, Peter A. Pircher, and Robert J. Muller 
Object-oriented structured design notation for software systems can serve the same purpose as schematics and block 
diagrams do for electrical engineering. 

64 a Hierarchical Taxonomic System for Computer 
Architectures 

Subrata Dasgupta 

Using formulas inspired by chemical notation, we can classify computer architectures in a way that provides both 
predictive power and explanatory capabilities. 
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LETTERS TO THE EDITOR 


In defense of DOS 

To the Editor: 

In January 1990, Computer devoted a 
significant chunk of its Product Reviews 
department to the virtues of Unix as an 
operating system for 386-based comput¬ 
ers [pp. 103-111]. I feel it is only fair to 
defend the opposition. 

Who says Unix is better? Most articles 
on Unix begin with statements like: 

“Once you get used to . . or “Once you 
get past the user unfriendliness . . Stop 
making excuses. Unix is a pain to work 
with. It has never made the slightest con¬ 
cession to the user. It was developed for 
programmers, by programmers. 

Yes, it is a powerful development en¬ 
vironment, but it is not a powerful appli¬ 
cation “execution” environment. DOS, 
on the other hand, was designed to facili¬ 
tate the use of applications by PC users 
who didn’t want to spend the rest of their 
lives learning all its nuances. Does this 
limit it as a development environment or 
as an effective utilizer of PC resources? 
Possibly, but I think DOS has generally 
improved faster than Unix. 

Try to think of a list of significant ap¬ 
plications that run under Unix. Time’s 
up. Can you count them on both hands? 
One hand? Can you think of one? The 
fact is, Unix is limited for the same rea¬ 
son CP/M bit the dust: it offers no sig¬ 
nificant applications. Some will argue 
that Unix has powerful text and graphical 
macros that compete in terms of power 
with equivalent DOS programs, but have 
you ever tried using them? They only 
make sense if you want to spend a week 
producing your next memo. “User 
friendly” they aren’t. 

There has been much ballyhoo about 
the ability of Unix to efficiently multi¬ 
task and transparently drive multiple ter¬ 
minals. So what? That capability only 
makes sense on something other than a 
PC, and a PC is what most of us use. 
There are maybe one or two power PC 
users in the world who really need to run 
multiple concurrent background func¬ 
tions, but do they want to run Unix Vi as 
a background? Not a chance; they want 
Microsoft Word as a background. Let’s 
see Unix do that. And running DOS pro¬ 
grams under Unix by running DOS as a 
subtask to Unix doesn’t count. You can’t 
bypass your own deficiencies by using 
another’s strengths. 


Actually, I suspect there is a certain 
snob appeal associated with Unix. I sus¬ 
pect that users, having gone through the 
agony of learning how to get things done 
with Unix, are reluctant to admit that the 
effort was essentially wasted. DOS, for 
all its flaws, is still the easiest way to 
make a PC do something. It comes the 
closest to making the PC a utility — 
something that you’re not terrified of 
turning off because you’re not sure you 
can get it started again. And a utility is 
all we’re after, isn’t it? If the PC envi¬ 
ronment becomes too difficult for the av¬ 
erage user, it won’t be used. Then we’ll 
need to look for different jobs — maybe 
making Unix look more like DOS. 

Michael R. Jude 

US West 

Keep IEEE standards 
international 

To the Editor: 

The December 1989 Standards column 
in Computer [pp. 73-74] outlined propos¬ 
als currently under consideration regard¬ 
ing management of IEEE standards. 
Fletcher Buckley took a stand against the 
proposal [to place all standards activities 
under IEEE-United States Activities] on 
the grounds that it would discourage the 
involvement of IEEE members not living 
in the US — a stand that I whole-heart¬ 
edly support. The standards-making 
process must, like IEEE conferences and 
workshops, be open to all who wish to 
participate. 

The column gave some examples to 
indicate the contribution made by IEEE 
members who are not US residents. I 
hope these examples were sufficient to 
convince readers, and those who will de¬ 
termine the proposal’s fate, that there is 
much to be lost by making “foreigners” 
even seem unwelcome, let alone barring 


their participation. To quote from the 
column, “. . . it would be a giant step 
backwards.” 

In case the point was not adequately 
made, I would like to outline the situ¬ 
ation for the PI 149.1 (Test Access Port 
and Boundary-Scan Architecture) proj¬ 
ect, which has just been submitted to the 
Standards Board for approval. This proj¬ 
ect was initiated in 1988 following an 
approach from an ad-hoc industry com¬ 
mittee called the Joint Test Action 
Group. JTAG was established in Europe 
in 1985 with the aim of creating an in¬ 
dustry standard for boundary-scan. 

Throughout, the involvement of Euro¬ 
peans in the PI 149.1 development has 
been significant: 

• Some 30 percent of the working 
group members are European, in¬ 
cluding myself (the chair). 

• Of those involved in the ballot, 23 
percent were not US residents, the 
majority being based in Europe. 

• A similar percentage of those who 
have asked for information on the 
project do not live in the US. 

The European interest in other IEEE 
standards is also significant. For ex¬ 
ample, many vendors of simulators that 
support the IEEE Std 1076 VHDL lan¬ 
guage have found the interest in their 
products to be greater in Europe than in 
the US. 

It is in the profession’s interest that 
IEEE standards continue to be an inter¬ 
national activity, open to all. This has 
been a key advantage of the IEEE’s stan¬ 
dards activities compared to the various 
national alternatives, for example, the 
British Standards Institute. The result has 
been that the IEEE has established a 
leading role in computer-oriented stan¬ 
dards. 

I can only hope that the proposal to 
bring IEEE standards under the control 
of IEEE-USA will shortly be abandoned. 

Colin Maunder 

British Telecom Research Labs 
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TeXpert opinion 


To the Editor: 

While “TeXnology on the IBM PC” 
[Computer, August 1989, pp. 111-120] is 
the best overview of TeX I’ve seen in 
some time. I’d like to bring up a few ad¬ 
ditional points. I think Frank Pappas 
could have made it clearer that the con¬ 
straints of space forced him to tell a few 
fibs, in the honorable tradition of Donald 
Knuth, who admits that he used them in 
his documentation. For example, the 
reader should not be left thinking that 
TeX will force him to rewrite to get rid 
of the black boxes that indicate less than 
perfect justification. You can also make 
the boxes invisible or simply tell TeX to 
be less fussy. 

Of greater interest to me is the fact 
that he did not mention any of the non¬ 
commercial versions of TeX for the PC. 
There are at least three, which can be ob¬ 
tained for the cost of copying. While not 
as fast or well documented as the best of 
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Gives your Computers Human Connection Through a Touch-Tone ® Telephone. 

• Excellence in Voice Quality • Digitizes Incoming & Outgoing Speech 

• Answers Incoming & Dials Outgoing Calls • Host lndependent/RS232 Interface 

• Touch-Tone® Generation & Decoding • Rack Mount (up to 10 lines) 

• Remote Hang-up Sensing • Special Information Tone Detection 

• External Switch Contact Recognition • Remote Relay/Switch Control 
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Alsys Ada cross-compilers 
get you there in no time. 



It’s time you knew that 
Alsys, the premier Ada company, 
offers a range of powerful and 
flexible cross-compilers for all 
microprocessors in the Motorola 
MC680X0 and Intel i80X86 
families* to get your applications 
up and running fast. 

Part of the reason for this 
speed are powerful development 
tools such as AdaProbe, a source 
level debugger and program 
viewer providing facilities to 
address both the execution prop¬ 
erties of a program and its static 
structure. In addition, there’s 
support for placing program 
components into ROM, and the 
Alsys Multi-Library Environ¬ 
ment allowing program units to 
be shared among libraries for 
team programming. 

With Alsys’ fuff line of 
cross-compifers you’ll discover 
impressive flexibility and power. 
There’s a configurable run-time 
system giving you full control 
over tasLs, interrupts and all 
components of your application. 
The debugger and transfer utility 
are configurable. Best of all, it’s 
easy to take advantage of all this 
power because there are only a 
few files to modify. 

When you need to get from 
here to there without getting lost 
somewhere in between, use a 
cross-compiler that knows the 
shortest route. 
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The 1990 INTERNATIONAL CONFERENCE ON COMPUTER-AIDED DESIGN will be held November 11-15, 1990 
ICCAD is oriented towards Electrical Engineering CAD professionals, concentrating on CAD for Electronic Circuit Design. 


AREAS OF INTEREST 

Original technical papers on (but not limited to) the following 
topics are invited: 

1 )HIGH LEVEL SIMULATION: Functional, Behavioral, Archi¬ 
tectural, Mixed-mode, Fault Simulation, HDL 

2) SIMULATION: Timing, Circuit, Device, Process Simula¬ 
tion, Modeling, Manufacturability, Hardware Acceleration 

3) HIGH LEVEL SYNTHESIS: Functional, Behavioral, Archi¬ 
tectural Synthesis, Silicon Compilation, DSP Synthesis, 
System Design, HDL 

4) LOGIC SYNTHESIS: Combinatorial, Synchronous, Asyn¬ 
chronous Logic Synthesis, Technology Mapping, Verifica¬ 
tion, Finite State Machine Synthesis, Optimal Clocking 

5) LAYOUT VERIFICATION/ANALOG CIRCUIT DESIGN: 
Circuit Extraction/Verification, DRC, ERC, Symbolic Design 
and Compaction, Module Generation, Analog Circuit Synthe¬ 
sis 

6) PLACEMENT AND FLOORPLANNING: Placement, 
Floorplanning, Partitioning, Area Estimation, Cell Layout, 
Layout Systems, Hardware Acceleration 

7) ROUTING: Routing for LSI, PCB and Multichip Substrate, 
Hardware Acceleration 

8) TESTING: Design for Testability, ATPG, BIST, Fault Diag¬ 
nosis 

9) CAD FRAMEWORKS: Tool Integration, Data Conversion, 
User Interfaces, DataBases, Design Languages, CASE 

AUTHOR INFORMATION 

Authors should submit 12 COPIES of: 

1) a one-paragraph abstract. 

2) a more detailed description not to exceed 18 double¬ 
spaced pages, figures and tables included. Excessively long 
submissions and previously published papers will be rez 

turned to the authors. 


FORMAT 

The ONE-PARAGRAPH ABSTRACT, typed on one separate 
page, should clearly and precisely state what is new and point 
out the significant results. Succinctness is required since this 
paragraph may be included in the Advance Program. In the 
detailed description, the author must objectively address why 
the proposed contribution is superior to prior work or what the 
significance of the contribution is, if breaking new ground. 
Demonstration of superiority in algorithms and strategies with 
heuristics is required through a description of the program¬ 
ming implementation and application to “real” problems. 
Additional mathematical proofs are welcome. The contribu¬ 
tion should address an area of current technical interest to the 
CAD professional. A cleardescription of the new contribution, 
status of the work and significant examples and results 
should be given. 

COVER PAGE REQUIREMENTS 

Submissions should include, on the cover page: the title of the 
paper; the category 1 - 9, which most clearly matches the 
paper’s content (see Areas of Interest); the full name, com¬ 
plete return address, telephone number and affiliation of 
each author; and clear identification of the individual to whom 
all communication should be addressed. In giving your return 
address, please consider that the communications for paper 
acceptance and mailing of the author’s kit occur in the month 
of July. 

AUTHOR’S SCHEDULE 
Deadline for submissions: April 27,1990 

Notification of acceptance: June 29,1990 

Deadline for final version: August 10,1990 

SEND TO: ICCAD-90 Secretary 
MP Associates, Inc. 

7490 Clubhouse Rd., Suite 102 
Boulder, CO 80301 
Telephone: (303) 530-4562 
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President’s MESSAGE 


& IntegrAda 


Let’s talk about a really big project! 

Imagine a project involving hun¬ 
dreds of scientists and engineers 
around the world — biologists, chem¬ 
ists, physicists, computer scientists, 
electrical engineers, aerospace engi¬ 
neers, oceanographers, meteorolo¬ 
gists, mathematicians, geologists, 
geographers, and many more. Now 
imagine these same people accessing 
and contributing to an international, 
distributed database that grows at the 
rate of over a terabyte per day. Much 
of this may become reality over the 
next decade in support of international activities to improve our 
understanding of the planet Earth and the role of man in chang¬ 
ing Earth’s environment. This broad area of study is termed 
global-change research. 

International global-change research activities are building on 
observations made by earth-orbiting weather and research satel¬ 
lites, atmospheric balloons, ships, and drifting buoys, and the 
analysis of such phenomena as ocean currents, cloud patterns, 
the movement and composition of glacier ice, the Antarctic 
“ozone hole,” earthquakes, volcanic activity, and tree rings. 

Most of what we read about global change focuses on the sci¬ 
ence, but it is interesting, in fact exciting, to look at it from an 
information technology perspective. What an application! The 
information technology challenges are staggering! We can envi¬ 
sion the evolution of loosely coupled, heterogeneous systems 
supporting users from many backgrounds; gigantic, distributed 
databases collecting, maintaining, and supplying data for uses 
beyond those originally intended; highly complex software sys¬ 
tems dynamically adapted to solve problems that cross numerous 
scientific disciplines; truly “open systems,” built on the informa¬ 
tion technology standards that we’re struggling to define and 
implement today. 

As your president, I am responsible for executing the Com¬ 
puter Society’s mission “to advance the theory, practice, and ap¬ 
plication of computing and information science and technology.” 
Many of the society’s current programs directly relate to solving 
the types of problems presented here — for example, publica¬ 
tions, technical meetings, standards development, and academic 
program accreditation. But what are we not doing that should be 
done? Your Computer Society must not only meet the profes¬ 
sional needs of its members today, but should attempt to antici¬ 
pate the needs of tomorrow as well. 

The society’s volunteer leaders do their best to keep the IEEE 
Computer Society the best and most exciting professional asso¬ 
ciation in the field. Still, we need the help of all the members if 
we are to maintain our success in the future. Check the list of 
Executive Committee and Board of Governors members (see 
p. 6). Let them know what you think we should be doing to con¬ 
tinue to be a vital part of our exciting professional future. If you 
don’t know any of them personally, write to me care of the Pub¬ 
lications Office in California. If your comments are brief, you 
may write them on the Reader Service Card (p. 104A). Just cir¬ 
cle number 180 and jot your comments on the back of the card. 

Helen M. Wood, Computer Society president 
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At Motorola Cellular, 
big thinking 
creates small miracles. 


In the rapidly growing cellular phone industry, Motorola is *\. We’ve beat 
all competitors in the race to introduce the world’s smallest hand-held 
personal cellular phone. We call it MicroTAC. Others call it a “miracle” 
of big thinking. .. a majortechnological advance in microchips, circuit 
boards and the manufacturing process. And this is just one of the 
breakthroughs resulting from the insights and ideas of Motorola 
engineers, who are making a big impact on communications by mak¬ 
ing the worldwide telecommunity smaller 
If you want to shape the future of cellular tech nology, consider one of 
the following opportunities: 


standards, ISDN standards, processor architectures, high-speed logic; 
16-bit MPU design practices, programmable logic; digital modulation 
synchronization, adaptive signal processing, viterbi algorithm and 
MLSE, decision Feedback equalizer; convolutional code and linear 
block code, speech coding, echo cancellation, encryption; CAE 
techniques for digital hardware design using Mentor Graphics, etc.; 
data communications protocols (CCITT *7, OSI, X.25, X.75, PAD, 
LAPB, LAPD, Ethernet, ISDN, CCITT V series modem, group 3 fax); 
computer network management/administration (ApollOi Sun, Mentor 
Graphics, AppleTalk). BSEE/MSEE/BSCE/BSCS or equivalent. Re¬ 
spond to Dept. EC. 



SOFTWARE: Real-time software development using C, UNIX’ 
Pascal, Ada, assembler and structured design; experience in soft¬ 
ware quality, metrics, ortesting; CASE software tools(Sun, Apollo); 
design, programming and system debugging for 
telephone digital switching or data communication 
systems; assembler and high-level structured 
languages; hardware diagnostics; object oriented 
design, C++; software development tools such as 
Teamwork and Interleaf; ASN.1 (Abstract Syntax Nota¬ 
tion); data comm unications protocols (CCITT *7 OSI, 

X.25, X.75, PAD, LAPB, LAPD, Ethernet, ISDN, 

CCITT V series modem, group3fax); model¬ 
ing and simulations(GPSS, SIMSCRIFTand j 
other simulation tools). BSEE/BSCS/BSCE I 
or equivalent. Respond to Dept. SW. f 

ELECTRICAL/COMPUTER: Analog and I 
RF circuit design, receiver or transmitter : 

RF circuits; LCD display technology, | 
acoustics, and 8-bit microprocessor soft- j 
ware; infrared and fiber optics; low speed f 
data; digital modulation; 900 Mhz RF 
power amplifier design with hybrid or 
microstrip circuitry; RF device develop¬ 
ment with device vendors; parallel and/or 
push-pull RF amplifier design at 900 
Mhz or UHF; A/D and D/A convertors; 

RF propagation; passive and active 
filter theory; microwave antenna 
design; UL, EMI and RFI require¬ 
ments; HP3062testsystem; HP9000; 
digital hardware, microprocessor ap¬ 
plications and interfaces; digital switch¬ 
ing technology; firmware develop¬ 
ment methodology; PCM and digital 
telephony; digital signal process¬ 
ing; ASIC design; LAN systems, PSTN 


MECHANICAL: Electronic packaging; CAD, CV CADDS 4X; 
materials selection and geometric tolerances and dimension¬ 
ing; extruded metal; injection molded plastics; 
life test procedures and factory introduction and 
support; plating materials and processes; structural 
analysis modeling; die casting and sheet metal 
stampings; thermal management. BSME/ MSME 
or equivalent. Respond to Dept. ME. 

SYSTEMS: Radio/cellular communication 
systems engineering; RF propagation prediction 
methods; PSTN traffic planning; telephone net¬ 
work, interconnection and telecommunication 
industry standards; microwave system design 
and equipment engineering; telephone 
switching systems; software programming 
skills. BSEE/BSCE/BSCS or equivalent. Re¬ 
spond to Dept. S. 

Forafuturewith acompany that will value 
and encourage your ideas, come to 
Motorola Cellular where you’ll find the chal¬ 
lenges for your big thinking. We offer an ex¬ 
cellent salary and a comprehensive bene¬ 
fits package. For immediate consideration, 
send your resume to: Supervisor, Pro¬ 
fessional Recruitment, Motorola, Inc., 
Cellular Group, 1501 West Shure Drive, 
Arlington Heights, IL60004. Or FAX your 
resume to: (708)632-5717 (our 24-hour 
FAX line). To access our On-Line 
Career Network from your PC, dial 
(708) 263-3857, press return twice 
and key in password LEGACY. We 
are an equal opportunity/affirma¬ 
tive action employer. 

•Registered trademark of AT&T 
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A Noninvasive 
Architecture to 
Monitor Real-Time 
Distributed Systems 



Jeffrey J.P. Tsai, Kwang-Ya Fang, and Horng-Yuan Chen 
University of Illinois at Chicago 


A real-time distributed computing 
system consists of a collection of 
communicating and cooperating 
processors or computers (nodes) that work 
toward a common goal. Critical timing 
constraints are imposed on them. 

The monitoring of real-time distributed 
computing systems involves the collection 
and interpretation of information, such as 
event time stamps, synchronization se¬ 
quences, race conditions, register status, 
transaction identifications, and interrupt 
activities. This information can be used for 
testing and debugging or improving the 
performance of distributed computing 
systems. 

However, monitoring a real-time dis¬ 
tributed computing system is much more 
difficult than monitoring a centralized, 
sequential computing system because of 

(1) Multiple asynchronous processes: 
Since real-time distributed computing 
systems feature asynchronous parallel 
processes, their computation shows non- 
deterministic and irreproducible behavior. 
This behavior, caused by race conditions 
and unpredictable synchronization among 


Equipped with a 
programmable 
qualification control unit 
for observing system 
states of a target node, 
this monitoring system 
can support 

performance evaluation, 
testing, and debugging 
of real-time distributed 
computing systems. 


processes, makes the results observed in a 
distributed computing system harder to 
understand and, in many cases, hard to re¬ 
produce. Usually, when a software system 


is executed on a real-time distributed 
computing system (such as a local net¬ 
work), deducing the execution order of 
instructions belonging to different pro¬ 
cesses of the system is impossible. 

(2) Critical timing constraints: For a 
real-time distributed computing system, 
the correctness of the system depends on 
its behavior with respect to time. Often, 
processes of a real-time distributed com¬ 
puting system are closely coupled to pro¬ 
cesses existing in the real world (such as a 
weapon system or a chemical plant). The 
correctness of a real-time distributed 
computing system, which depends on the 
performance of underlying processors, is 
determined by meeting the timing con¬ 
straints imposed by the real-world pro¬ 
cesses. Any interference in the monitoring 
activity in the real-time distributed envi¬ 
ronment is intolerable. 

(3) Significant communication delays: 
The nodes of a real-time distributed com¬ 
puting system can be geographically dis¬ 
persed. This may introduce a significant 
communication delay, which can in turn 
cause improper synchronization among 
the processors and make it difficult to de- 
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termine the precise global time and accu¬ 
rate global state. 

As a result of these differences, the 
execution of a real-time distributed com¬ 
puting system is characterized by nonde¬ 
terminism, timing constraints, and the low 
visibility of system behavior. These char¬ 
acteristics make the monitoring of the 
global states and the execution flows of a 
real-time distributed computing system 
almost impossible. Thus, the global timing 
and state that represent the system’s run¬ 
time behavior are difficult to observe. In 
addition, almost all existing monitoring 
systems are designed to share computing 
resources. 1 ' 8 

These monitoring systems apply con¬ 
stant interference to a target distributed 
computing system, change system behav¬ 
ior, and degrade system performance. 
Therefore, these techniques are not suit¬ 
able for monitoring real-time distributed 
computing systems. We need a new ap¬ 
proach for system monitoring and data 
collection that doesn’t interfere with sys¬ 
tem execution behavior. 

In the past few years, research has been 
actively carried out in an attempt to moni¬ 
tor the execution behavior of distributed 
and parallel systems. 3 - 6 ' 8 Joyce et al. pre¬ 
sented a distributed monitoring system that 
can collect, interpret, and display informa¬ 
tion concerning interactions among con¬ 
currently executing processes. 3 To allow 
interprocess events to be easily detected, 
Joyce modified the processes to be moni¬ 
tored by loading them with a version of 
interprocess communication protocol that 
incorporates monitoring. The modified 
processes, called “monitorable processes,” 
suffer a certain degree of execution speed 
penalty. 

Plattner described an experimental real¬ 
time monitoring system that can be used to 
observe the behavior of real-time pro¬ 
cesses, to collect trace data, and to detect 
illegal or unexpected process states. 6 This 
monitoring system is capable of monitor¬ 
ing processes written in a high-level pro¬ 
gramming language, in real-time, and on a 
symbolic level. Planner’s experience with 
this experimental monitoring system 
shows limitations of the monitoring activ¬ 
ity that can be achieved by the monitor. 

Snodgrass views monitoring as an infor¬ 
mation-processing activity and asserted 
that the relational model is an appropriate 
formalism for structuring the information 
generated by a distributed computing sys¬ 
tem. 7 His work focuses on the query of a 
relational database model so that the user 


can specify what information is to be col¬ 
lected. This approach controls the amount 
of monitoring data collected and thus alle¬ 
viates the invasive nature of a monitor. 

Tokuda et al. presented a real-time 
monitor that is being built for a distributed 
real-time operating system. 8 This real-time 
monitor is an invasive monitoring system 
in the sense that it needs extra kernel sup¬ 
port. 

Although much research has been done 
and many tools for monitoring have been 
developed, they are still not practical for 
monitoring real-time distributed comput¬ 
ing systems due to a monitor’s invasive 
nature. In this article, we present a hard¬ 
ware architecture for a noninvasive moni¬ 
toring of real-time distributed computing 
systems. 

Our principal objective here is to de¬ 
velop a real-time monitoring system to 
ensure minimal interference in the execu¬ 
tion of a target distributed computing sys¬ 
tem. This system should also provide users 
with a tool to support either top-down or 
bottom-up approaches for testing and de¬ 
bugging, as well as performance evalu¬ 
ation of real-time distributed computing 
systems. 

This monitoring system extracts infor¬ 
mation directly from traffic on the internal 
buses of a target distributed computing 
system. Since modifying a target distrib¬ 
uted computing system or sharing comput¬ 
ing resources with the target system is not 
required, our architecture does not inter¬ 
fere with the execution of the target system 
and guarantees the preservation of the 
timing constraints. 

In the following sections, we describe a 
model of real-time distributed computing 
systems; present the hardware architec¬ 
ture, operation, and implementation of our 
noninvasive monitoring system; introduce 
our approach to the noninvasive monitor¬ 
ing of real-time distributed computing 
systems; demonstrate how this approach 
can be used to support the testing and 
debugging of real-time distributed com¬ 
puting systems; summarize the advantages 
of our approach; and discuss the direction 
of future work. 


A model of real-time 
distributed computing 
systems 

A real-time distributed computing sys¬ 
tem, used for real-time distributed applica¬ 
tions, consists of a hardware part and a 


software part. The hardware part shown in 
Figure 1 includes a collection of nodes and 
a communication network. Each node has 
its own CPU, memory, peripherals, and 
communication interface. The software 
part, which executes on each node of a 
real-time distributed computing system as 
shown in Figure 2, includes the operating 
system, the communication module, and a 
collection of application processes. The 
operating system is in charge of scheduling 
the application processes and managing 
the local resources. The communication 
module is responsible for internode com¬ 
munication. 

To simplify the description of the moni¬ 
toring system, we assume that the target 
system is a dedicated real-time distributed 
computing system. Furthermore, our ap¬ 
proach toward noninvasive monitoring is 
based on the following assumptions* about 
the monitored system: 

(1) It is a distributed/multiprocessor 
system with a master node (processor) and 
a set of slave nodes as shown in Figure 1. 
The master node controls all interactions 
among the slave nodes, and each node has 
its own local storage. Since the monitoring 
system is independent of the communica¬ 
tion subsystem, there is no further restric¬ 
tion on the topology of connection of real¬ 
time distributed computing systems. 

(2) Communications among processes 
residing on a node take place via shared 
variables, while the interactions among 
processes residing on different nodes take 
place through message exchanges. 

(3) Process migration among nodes is 
not allowed during the monitoring of dis¬ 
tributed computing systems. Thus, the 
communication subsystem is dedicated to 
communication activities among nodes. 

(4) Processes perform input and output 
operations by asking for service from the 
operating system. Input to a target distrib¬ 
uted computing system is asynchronous. 
This assumption, together with the follow¬ 
ing assumptions, eases the identification 
of process-level and function-level events 
(see the section entitled “Monitoring in 
different abstraction levels”). 

(5) For the application software, we 
assume that procedural calls are imple¬ 
mented by system calls, while recursive 
calls of a procedure are not allowed. In a 
procedural call, the symbolic name of a 


* The main purpose of these assumptions is to ease the 

simplify the trigger conditions and reduce the com¬ 
plexity of the postprocessing mechanism. 
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Slave node 1 Slave node N 



Figure 1. Hardware view of a real-time distributed computing system. 


Slave node 1 Slave node 2 Slave node N 



Master node 


Figure 2. Software view of a real-time distributed computing system. 


procedure can uniquely be identified. 
Device interrupts can be separated using 
unique device identification in the col¬ 
lected trace. All computational entities 
(processes/procedures) should be address¬ 


able using names and descriptors main¬ 
tained in a system symbol table. 

(6) Our current design is based on the 
MC68000 computer. If the target system is 
not the same kind ofhardware architecture 


(for instance, in modern distributed sys¬ 
tems that utilize caching and prefetching), 
the monitoring system architecture and the 
postprocessing mechanism will require 
modification. 
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An architecture for 
real-time distributed 
computing system 
monitoring 

The system architecture of the noninva- 
sive monitoring system, as shown in Fig¬ 
ure 3, consists of two major components: 
the interface module and the development 
module. 

The interface module can be considered 
as the front end of the monitoring system. 
This module is specially designed to attach 
to and interface with the specific real-time 
distributed computing system for system 
monitoring and data collection. Its main 
function is to latch the internal states of the 
target system based on predefined condi¬ 
tions set by the user. 

The development module is the host 
computer for the interface module. This 
module is a general-purpose microproces¬ 
sor-based system that contains all the sup¬ 
porting software for the initialization of 
the interface module and postprocessing 
activities. 

Since the noninvasive monitoring sys¬ 
tem does not steal CPU time from the 


target real-time distributed computing 
system, it does not interfere with target 
system execution. The monitoring system 
provides noninvasive features of system 
monitoring and execution history record¬ 
ing by connecting itself with the internal 
buses of the monitored node and by latch¬ 
ing data directly from them. Referring to 
the system architecture shown in Figure 3, 
the monitoring system, after being con¬ 
nected to a node of the target system and 
initialized, continues monitoring and col¬ 
lecting events of interest until it detects a 
“stop” condition, specified by the user. 
Execution history recording is controlled 
by the qualification control unit (Figure 4) 
in the interface module. The QCU samples 
the state of the target processor via its 
internal buses during every processor 
cycle. A user-selected state or breakpoint 
is used as a trigger to initiate and to stop 
recording of the runtime information. 

The interface module. The main func¬ 
tion of the interface module is to copy the 
internal states of the target node’s proces¬ 
sor and, under predefined trigger condi¬ 
tions, to start recording data from the buses 
of the target node onto the memory buffer 


unit. As shown in Figure 4, the interface 
module consists of five functional units: 

• the interface control unit (ICU), 

• the dual processor unit (DPU), 

• the dual processor memory (DPM), 

• the qualification control unit (QCU), 
and 

• the high-speed buffer unit (HSBU). 

The monitoring system is connected to 
the target node via the ICU. The DPU 
contains a dual processor identical to the 
target processor and the DPM, which is 
used for the synchronization of the dual 
processor with the target processor. The 
main function of the DPU is to snapshot the 
target node processor’s state at the begin¬ 
ning of recording the target node’s execu¬ 
tion behavior. 

To achieve a true noninvasive condition 
during the time of execution history re¬ 
cording, the DPU is designed to imitate the 
target processor after it has been initiated 
and synchronized until the recording of the 
execution history is started. Therefore, the 
corresponding state of the target processor 
at the beginning of execution history can 
be kept in the dual processor. 


To communication network 



Figure 3. System overview. 
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Figure 4. Interface module and development module. 


The QCU processes the preset trigger 
condition into a control signal to initiate 
and stop data recording. Usually, the speed 
of the target node’s system buses is very 
high. To store this high volume of latched 
data, we need a lot of high-speed memory, 
which is very expensive. Hence, we adopt 
a cheaper design method in the HSBU. 
Instead of using a lot of high-speed mem¬ 
ory, we use a high-speed register as a 
buffer between the target node’s system 
buses and the development module’s 
memory. The latched data is first written 
into a high-speed buffer and then trans¬ 
ferred into the development module’s 
memory. 

To initialize the monitoring system, a 
low-priority interrupt is sent by the DPU 
for initializing and synchronizing itself 
with the target node’s processor. This 
interrupt is the only interference in the 
target node’s processor by the monitoring 
system. 

The purpose of sending such a low- 
priority interrupt signal is to avoid interfer¬ 
ing with the target processor, especially 
when the target system is performing criti¬ 
cal timing tasks. Because of its low prior¬ 
ity, the impact of the interrupt on the target 
node is assumed to be minimal. 

If the target system is performing a criti¬ 
cal computing task, or if it is in a heavy 
work-load condition, the response to the 
low-priority interrupt may be delayed. The 
interference caused by this interrupt is 
minimal and reasonably tolerable because 
the initialization of the interface module is 
only executed at noncritical and nonbusy 
times. 

This interrupt signal triggers an inter¬ 
rupt service routine in the target node to 
start initialization of the interface module 
by copying all register contents to the DPU. 
After the DPU is initialized and both of the 
processors are synchronized, the monitor¬ 
ing system is ready to monitor the target 
node’s execution behavior and collect 
runtime information. 

After the first step of initialization, the 
dual processor starts to mimic the opera¬ 
tion of the target node processor without 
physically accessing the memory and pe¬ 
ripheral devices of the target node. 

This synchronization remains until a 
starting trigger is matched in the QCU. In 
this case, the starting trigger is matched 
and the QCU generates and sends control 
signals to the HSBU and DPU to indicate 
that a preset condition has been matched. 
As soon as the control signal is received, 
the dual processor isolates itself from the 
target node to freeze and save the internal 


state of the target processor in the dual 
processor memory and, simultaneously, 
the HSBU starts loading data from the 
buses of the target node. 

The data acquisition rate is determined 
by the speed of the communication bus of 
the target system. The monitoring activity 
continues until the preset stopping trigger 
is matched in the QCU. At this point, the 
QCU sends a signal to the HSBU to stop 
monitoring the target node’s execution 
behavior. The recorded information is then 
transferred to the development memory 
unit for postprocessing. 

Interface control unit. The function of 
the ICU is to establish a connection be¬ 
tween the target node and the monitoring 
system without creating electrical inter¬ 
ruptions for the target processor. When the 
monitoring system and target node are 
connected, the data, address, and control 
signals are connected by a two-stage tri¬ 
state buffer switch, as shown in Figure 5. 

The first-stage switch is controlled by an 
initialization done signal. The second- 
stage switch is controlled by a control 


circuit in the interface module. The On or 
Off status of the second-stage switch indi¬ 
cates whether the dual processor is running 
in synchronization with the target proces¬ 
sor or running independently. When the 
synchronization process is completed 
(Off), the switch becomes active (On) and 
the logical connection between the target 
processor and the dual processor via data 
and control buses is established. 

When a starting trigger is matched in the 
QCU, the dual processor separates itself 
from the target processor and starts run¬ 
ning independently. At this time, the sec¬ 
ond-stage switch is deactivated and the 
logical connection between two proces¬ 
sors is disconnected. 

The ICU is target node-dependent and 
constructed to support synchronization 
and concurrent operation with the dual 
processor on the same bus as the target 
processor. The ICU reconfigures the 
memory structures so that, during the dual 
processor’s imitation of the target proces¬ 
sor, memory write operations from the 
dual processor are intercepted without 
physically accessing the target node’s 
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Figure 5. Interface control unit (ICU). 


memory, avoiding memory contention 
caused by two processors. 

Dual processor unit. The DPU is de¬ 
signed to capture the target processor’s 
internal state at the beginning of monitor¬ 
ing. To achieve this, the DPU must be 
initialized and synchronized with the tar¬ 
get processor. After both processors are 
synchronized, the dual processor reads the 
target processor’s data bus; thus, it will 
read the same instruction as the target 
processor and will start mimicking the 
target node processor. The sequence of 
activities performed in the initialization of 
the DPU can be briefly described as fol¬ 
lows: 

(1) Reset the dual processor and inter¬ 
rupt the target node processor at low 
priority. 

(2) Wait for the target processor to 
transfer its internal state. 

(3) Synchronize the dual processor with 
the target processor. 

At the time of power-up, the dual pro¬ 
cessor is reset to prepare it for the transfer 
of information from the target processor 
and to interrupt the target processor at low 
priority to get its attention for transferring 


the data. The DPU then waits for the re¬ 
sponse from the target processor so it is 
synchronized with the target processor. 

Synchronization allows the dual proces¬ 
sor to concurrently mimic the target pro¬ 
cessor’s activity until the recording trig¬ 
gers are activated. Different synchroniza¬ 
tion techniques can be used to create a 
communication link between two proces¬ 
sors. The direct synchronization tech¬ 
nique, which was originally designed to 
utilize the processor’s ability to communi¬ 
cate with slow peripheral devices, is used 
to achieve the required minimal interfer¬ 
ence with the target processor. 

To mimic the behavior of the target 
processor, the program counter, status 
flags, and internal registers of the target 
processor need to be stored to the dual 
processor. After the target processor re¬ 
sponds to the interrupt from the develop¬ 
ment processor, the interrupt routine trans¬ 
fers all the internal registers of the target 
processor to a dummy I/O peripheral: the 
dual processor. 

The dual processor is reset by the “in¬ 
take” signal from the target processor and 
starts its own service routine to read the 
data bus of the target processor through a 
dummy I/O port. Multiplexers are used to 
switch the data bus from the dual processor 


to the target processor. Whenever the dual 
processor issues an I/O read signal to the 
dummy I/O port, this signal is combined 
with the I/O address to switch the dual 
processor’s data bus toward the target 
processor’s data bus. Thus, whenever the 
dual processor reads that particular I/O 
device, the data is read from the target 
processor’s data bus. 

Whenever the target processor writes to 
a dummy I/O address, it temporarily puts 
itself into a wait state. It does this by using 
I/O write control of the target processor as 
a “device-not-ready” signal to the target 
processor via a flip-flop. This flip-flop 
remains set until the dual processor again 
reads its dummy I/O port, which resets it. 

There are two comparators, Cl and C2. 
Cl is connected to the target processor’s 
data bus, and C2 is connected to the dual 
processor’s data bus. These comparators 
compare the data flowing through the data 
bus to detect the last instruction in the 
target processor’s service routine (which is 
instruction RTI, for return from interrupt). 

When this instruction is fetched by the 
target processor, the Cl comparator issues 
a “match” signal. This output signal is 
connected to the device-not-ready line of 
the target processor to force it into a wait 
state. Similarly when the dual processor 
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Figure 6. Qualification control unit (QCU). 


fetches its last instruction (which can be 
set by the designer), the C2 comparator 
will also issue a “match” signal to force the 
dual processor into a wait state by pulling 
the dual processor’s device-not-ready line 
active. 

Since both processors share the same 
clock, their wait states will be the same. 
After the dual processor is forced into a 
wait state, the “match” signal is used to 
switch the data, control, and address buses 
of the dual processor to the target proces¬ 
sor. After switching, the dual processor 
can only read the data and the address 
buses of the target processor. 

At the time of the write operation, the 
write signal of the dual processor is used to 
switch its data bus to a register. Thus, at 
every write operation, the dual processor 
will write to this register and, at every read 
operation, it will read the target proces¬ 
sor’s data bus. In addition, the dual proces¬ 
sor will get all the incoming control signals 
from the target processor, although the 
outgoing signals of the dual processors are 
floated. 

After the delay of all this switching, the 
match signal of the comparator (C2), 
which is connected to the dual processor, is 
used to bring both the processors out of 
their wait states by pulling the device-not- 
ready line inactive. When the target pro¬ 
cessor comes out of the wait state, it exe¬ 
cutes the return instruction. The dual pro¬ 
cessor and the target processor will receive 
the same instruction since they share the 
same data bus. At this moment, two pro¬ 
cessors are performing the same opera¬ 
tions with the target processor as the mas¬ 
ter of the bus control. 

Qualification control unit. Figure 6 
shows the block diagram of the QCU. The 
development processor unit can set the 
QCU to various conditions. Besides the 
decoder, the design shown in Figure 6 is 
simply divided into two basic blocks. One 
is the comparison logic circuit, which is 
composed of a number of comparators. 
Each comparator can issue three basic 
condition signals, “equal,” “greater than,” 
and “less than,” representing these differ¬ 
ent conditions based on the result of the 
comparison. The other circuit is the combi¬ 
nation logic that combines the basic condi¬ 
tions generated by the comparison unit and 
generates control signals. 

The QCU monitors system execution by 
sampling the distributed computing states 
of the target processor during each bus 
cycle. If the sampled state matches any 
user-specified conditions, the recording of 


distributed execution history is triggered. 
At this point, the dual processor receives 
an interrupt signal from the QCU and sepa¬ 
rates itself from the target processor. An 
image of the target processor’s state corre¬ 
sponding to the beginning of the execution 
history is therefore frozen in the dual pro¬ 
cessor. 

The QCU consists of a logic circuit that 
compares the signals on the buses of the 
target processor against the preset trigger 
conditions. The QCU may be designed 
with multiple counters to record the prehis¬ 
tory, posthistory, or some combination 
relative to the occurrence of a trigger con¬ 
dition. 

In addition to simple concurrent com¬ 
parisons, the trigger condition may also be 
set up to be sequenced in hardware. That is, 
a given trigger can be initiated to become 
active only if another trigger occurs first. 
The length of the execution history is 
controlled by a trace counter to count the 


number of cycles being recorded, or by the 
detection of a stopping trigger specified by 
the user. When a predefined length of the 
execution history has been recorded, the 
recording process is automatically 
stopped. 

The QCU is actually a hardware im¬ 
plementation of software breakpoints de¬ 
fined by the user through the development 
processor. The comparison logic circuit in 
the QCU is primarily a programmable 
logic array design that gives the maximum 
flexibility required to support general soft¬ 
ware breakpoint conditions. The specific 
timing constraint is a critical issue in the 
design of the QCU because the comparison 
operation must be completed within one 
bus cycle and the control signals are also 
generated accordingly. 

The development module. The devel¬ 
opment module, which consists of the 
development processor unit and the devel- 
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Figure 7. Memory interleaved technique. 


opment memory unit, is the central pro¬ 
cessing unit of the monitoring system and 
functions as a host machine. The develop¬ 
ment module is basically independent of 
the target node processor. Independence is 
achieved by separating the target-depen- 
dent functions into the interface module. 
The development module provides an 
interactive interface to the user and is re¬ 
sponsible for all the testing and debugging 
activities, including 

(1) initialization of the monitoring sys- 

(2) controlling the interface module to 
latch the target node execution his¬ 
tory, and 

(3) performing postprocessing on re¬ 
corded execution history. 

Postprocessing, a very important activ¬ 
ity supported by the development proces¬ 
sor unit, is basically system dependent. Its 
main function is to process the recorded 
execution history (see the section entitled 


“Postprocessing of traces”). The other 
functions of the development processor 
are 

(1) To initialize the interface module. 
On “system power-on” or “system reset,” 
the development processor initiates a sys¬ 
tem hardware initialization and loads the 
checkpoint (breakpoint) conditions into 
the QCU. 

(2) To provide a user-friendly interface. 
The development processor provides a 
user-friendly interface under various situ¬ 
ations such as prompts for trigger condi¬ 
tion setup or display messages on various 
system activities. 

The development memory unit consists 
of two parts: the development processor 
memory and the memory configuration 
unit. Through the HSBU, the program 
execution history from the target node is 
latched into the memory configuration 

The memory interleaved technique, 


applied in designing the memory configu¬ 
ration unit, is used to give sufficient time 
for memory access when the bus cycle of 
the target processor is much faster than the 
memory used (see Figure 7). By applying 
this, cheaper memory (such as dynamic 
cell memory, which has higher storage 
density but needs more access time) can 
be used in the development processor 
memory. 

Memory is divided into several banks 
depending on the speed of the memory and 
the length of the target processor bus cycle. 
The slower the memory or the faster the 
bus cycle, the more memory banks are 
required. The memory bank is identified 
by the least significant address bits, and the 
remainder of the address bits specify ad¬ 
dress within a memory bank. The least 
significant memory address bits are de¬ 
coded to generate a memory bank selection 
control signal that selects a different 
memory bank at each bus cycle so suffi¬ 
cient time is given to access the memory 
bank. 
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Monitoring in 
different abstraction 
levels 

Different levels of monitoring provide 
different levels of detail for different appli¬ 
cation purposes. Higher level monitoring 
is concerned with information pertaining 
to events such as intemode communica¬ 
tion. By comparison, lower level monitor¬ 
ing is concerned with information that 
pertains to events such as the step-by-step 
execution trace of a process. 

The monitoring system presented here 
supports different abstraction levels of 
monitoring according to application pur¬ 
poses. It can monitor process-level activi¬ 
ties (for example, intemode or intranode 
communication) and function-level activi¬ 
ties (for example, procedure calls) as well 
as instruction-level activities (for ex¬ 
ample, step-by-step instruction trace). A 
detailed description of process-level moni¬ 
toring is given in the following section. 

The monitoring system achieves differ¬ 
ent levels of monitoring by setting the 
QCU according to the classes of events it is 
interested in. Based on the purpose of 
monitoring, the users may set up their own 
trigger conditions on the QCU to record 
specific classes of events. 

Due to the flexibility of the QCU, the 
monitoring system can support either bot¬ 
tom-up or top-down approaches to testing 
and debugging, as well as system perform¬ 
ance evaluation of real-time distributed 
computing systems. For instance, to re¬ 
duce the complexity of the debugging 
procedure, we may adopt a top-down ap¬ 
proach to the monitoring of a real-time 
distributed computing system. 

Initially, the monitoring system is at¬ 
tached to the master node to observe exe¬ 
cution of the target distributed system. The 
execution behavior of the master node is 
watched and recorded. To examine the 
interprocess interaction between nodes, 
additional monitoring systems need to at¬ 
tach simultaneously to these correspond¬ 
ing nodes. 

Finally, if the user is interested in the 
behavior of an individual process, the 
monitoring system is attached to the node 
where the process resides so the events 
pertaining to the behavior of the process 
can be collected by setting up the QCU 
appropriately. 

Process-level monitoring. As stated 
above, monitoring process-level activities 
provides a high-level view of the target 


system’s behavior. To characterize this 
behavior, we identify the following events 
with specified key values as typical pro- 
cess-level events: 

(1) Creating and terminating process: 

(a) Creating process: parent pro¬ 
cess identification, child pro¬ 
cess identification, time. 

(b) Terminating process: parent 
process identification, termi¬ 
nating process identification, 
terminating state, time. 

(2) Process synchronization: process 
identification, operation (P/V), 
semaphore identification (see the 
sidebar), the value of the sema¬ 
phore, time. 

(3) Interprocess communication: 

(a) Direct communication: process 
identification, operation (send/ 
receive), process identification 
(send to or receive from), mes¬ 
sage, time. 

(b) Indirect communication: pro¬ 
cess identification, operation 
(send/receive), mailbox identi¬ 
fication, message, time. 

(4) External signals: 

(a) Hardware clock interrupt: pro¬ 
cess identification (running 
process), process identification 
(resumed process), time. 

(b) I/O completion interrupt: pro¬ 
cess identification (running 
process), process identification 
(resumed process), message 
(I/O buffer), time. 

To monitor the process-level events 
listed above, we need to preset two sets of 
trigger conditions into the QCU of the 
interface module: starting trigger condi¬ 
tions, which start the recording process, 


and stopping trigger conditions, which 
stop the recording process. The trigger 
conditions are identified such that the re¬ 
cording process is started when one or a 
sequence of events occurs. The recording 
process is stopped when the key values of 
the event(s) are included in the recorded 
data block. 

The control flow of monitoring can be 
described as follows. The monitoring sys¬ 
tem is initialized and connected to the 
individual node of the target distributed 
computing system. The identified starting 
and stopping trigger conditions are initial¬ 
ized in the QCU of the interface module. 

During system execution, the QCU 
samples the states of the target system. The 
QCU continues sampling and recording 
the process-level events until the execu¬ 
tion of the monitored system is stopped or 
until a “stop” condition, specified by the 
user, is detected. 

The activities of the process-level moni¬ 
toring of a real-time distributed computing 
system can be summarized as follows: 

(1) connect the monitoring system to a 
node of the target distributed com¬ 
puting system without electronic 
interruption, 

(2) load trigger conditions for start and 
stop of process-level events record¬ 
ing, 

(3) initialize the interface module, 

(4) record process-level information, 
and 

(5) transfer recorded information to 
secondary storage for post¬ 
processing. 

Setting trigger conditions for process- 
level monitoring. To identify the starting 
and stopping trigger conditions, we next 
describe how the process-level events 


Semaphores 

Semaphores are a commonly used mechanism for implementing process syn¬ 
chronization. A semaphore is an integer variable S for an associated group of wait¬ 
ing processes upon which only two operations, P and V, may be performed: 

P(S): if S > 0 then 

S = S-1 

else the executing process is suspended and placed in S’s waiting group 

endif 

V(S): if S's waiting queue is nonempty then 

remove one waiting process and wake it up for execution 
else S = S + 1 
endif 
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occur in a real-time distributed computing 
system. In our discussion, the operating 
system is treated as an interrupt-driven 
process. 9 When an interrupt (or trap) oc¬ 
curs, the hardware transfers control to the 
operating system, which then determines 
what kind of interrupt has occurred. A 
process requests system resources or ser¬ 
vices from the operating system by execut¬ 
ing a system call, a privileged instruction 
with parameters to specify what is re¬ 
quested. 

When a process executes a system call, 
a software interrupt occurs and the operat¬ 
ing system transfers control through a 
predefined interrupt vector to a system 
service routine. This system service rou¬ 
tine executes the request on behalf of the 
process. 

If the interrupt is an I/O completion from 
a device, the operating system awakens the 
process waiting for this I/O completion. 
All other process-level events are handled 
by the operating system in the same man¬ 
ner. For example, in the case of an indirect 
communication, messages are sent to and 
received from mailboxes. Each mailbox 
has a unique identification that distin¬ 
guishes it. In this scheme, a process may 
communicate with some other processes 
by a number of different mailboxes. 

A mailbox may be associated with more 
than two processes. The operating system 
provides two system calls to let processes 
send or receive messages with the mail¬ 
box’s identification and the messages as 
parameters of the system calls. 

Based on the description above, we can 
set the trigger conditions to identify sys¬ 
tem calls related to the process-level 
events. We summarize the following five 
conditions as starting trigger conditions 
for the process-level events described in 
the section entitled “Process-level moni¬ 
toring”: 

IF ((system call interrupt) AND 
(process related activities)) 

OR ((system call interrupt) AND 
(I/O request)) 

OR (I/O completion interrupt) 

OR (system clock interrupt) 

OR (program error interrupt) 

THEN trigger the recording process. 

No matter what type of interrupts are 
caused by the events, the operating system 
will return control to an application pro¬ 
cess after the service for the interrupt is 
finished. This is done by the operating 
system executing a privileged instruction 


that changes the system mode to user 
mode. So, the stopping condition for all the 
events can be: 

IF (instruction changes the system 
mode to user mode) 

THEN stop the recording process. 

The information concerned with pro- 
cess-level events is collected from the tar¬ 
get distributed computing system as a data 
block that contains the key values for the 
event(s). The development memory unit 
containing the collected data can be ar¬ 
ranged to be large enough to save the event 
history. 

When the QCU is detecting the next 
trigger condition, collected data in the 
development memory unit can be saved to 
a secondary storage so the development 
memory unit can be used to receive new 
data. By considering the time for the oper¬ 
ating system to perform a context switch 
before it can respond to the new interrupt, 
it is easy to calculate and allocate enough 
memory space in the development module 
so continuous data recording and system 
monitoring can be achieved. If the context 
switch time is not long enough for transfer¬ 
ring the collected data into the mass stor¬ 
age, the memory space required for the 
development module can be estimated as 
described below. 

In the worst case, let R be the largest 
number of events happening continuously, 
and let s be the largest system service 
routine size (in bytes). Then the required 
memory space, S, will be 

S = cxsxR 

where c is a constant. Usually, it is very 
difficult to estimate the exact value of R. 
However, for a certain target system, an 
estimated average value of R, r, can always 
be obtained through experiments. Thus, on 
average, 

S = cxsxr 

where r is the event coming rate (happen¬ 
ing rate), and it is target system dependent. 

Since the “buffer” technique can be used 
in designing the development memory 
unit, the constant c in these equations can 
be very small (for example, c = 2). In 
general, the memory space, required in 
storing the collected data, is application- 
and target-system dependent. For instance, 
the less frequently communication/syn¬ 
chronization occurs among processes, the 
less memory space is required. 


Postprocessing of traces. As described 
above, system behavior is monitored and 
recorded in the machine-level code, which 
is hard to comprehend and not easy to use. 
The collected data contains not only the 
key values of events but also other irrele¬ 
vant instructions and data. Furthermore, 
interpretation of the collected data will be 
target-processor dependent. Therefore, it 
is important to eliminate the useless infor¬ 
mation and provide only the event infor¬ 
mation to the user. 

When collecting traces from the target 
system, virtual addresses are the predomi¬ 
nant signals on which to trigger and col¬ 
lect. The interpretation of what went on in 
the target system (that is, the identification 
of events as well as the mapping of physi¬ 
cal addresses and their corresponding logi¬ 
cal addresses) is done with the help of 
system tables. 

In postprocessing the collected data, 
redundant data irrelevant to the event are 
removed. The collected data are then reor¬ 
ganized into different-level logical views 
of events determined by the user. The col¬ 
lected data is processed and reorganized 
into an intermediate data set, called the 
integrated process-level execution log. 
The IPEL contains only the key values and 
control data to identify the events and is 
constructed in such a way that some higher 
level logical views can be derived easily. 

As shown in Figure 8, the IPEL consists 
of two related data structures called the 
process creation table and the event chain. 
The PCT presents the processes and their 
relations. Each entry of the PCT, corre¬ 
sponding to a process in the system, gives 
the process identification, its parent pro¬ 
cess identification, and the time the pro¬ 
cess was created. The event chain consists 
of a single-linked list of process-level 
events that describes what has happened in 
the system. Each node of the event chain 
that corresponds to an event contains the 
key values of the event (as defined in the 
“Process-level monitoring” section) and 
two pointers. One pointer is used to link all 
the events in time sequence (time link) so 
the logical views related to multiple pro¬ 
cesses can be derived by searching the 
events on the time link. The other pointer 
links all the events related to one process in 
time sequence, called the process link, 
such that the logical views concerning a 
particular process can be derived by 
searching the events on the process link. 

Here, we present a simple example to 
illustrate the postprocessed execution in¬ 
formation. The program shown in Figure 9 
is monitored on a Unix operating system. 
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We assume that the monitoring starts at the 
beginning of the execution of the program. 
Figure 10 shows the intermediate data set 
after postprocessing the recorded informa- 


Applications 

Performance evaluation, testing, and 
debugging are common tasks in develop¬ 
ing and maintaining real-time distributed 
computing systems. These tasks require 
detailed insight into a program’s execution 
behavior, which is not possible to compre¬ 
hend by simply examining the static as¬ 
pects of the program. Conventional moni¬ 
toring facilities provide tools to monitor 
system behavior and collect execution data 
to support testing, debugging, and measur¬ 
ing system performance. However, due to 
the invasive nature of monitoring, conven¬ 
tional approaches are inadequate for moni¬ 
toring real-time distributed computing 
systems. In this section, we describe how 
our approach to monitoring system behav¬ 
ior can be used to support the testing and 
debugging of real-time distributed com¬ 
puting systems. 

In demonstrating the presence of pro¬ 
gram errors or the localization and correc¬ 
tion of erroneous program code, it is neces¬ 
sary to repeatedly examine the execution 



Figure 8. Logical view of the integrated process-level execution log (IPEL). 


main() 

{ int pid; 
int code = 0; 

pid = fork(); 

/* create a new process */ 

if (pid == 0) 

code++; 

/* segment of new process */ 

else { 

/* segment of parent process */ 

wait(); 

/* wait for the termination of the child process */ 

pid = forkQ; 

/* create another new process */ 

if (pid == 0) 

code++; 

/* segment of new process */ 

else 

/* segment of parent process */ 

wait(); 

} 

} 

/* wait for the termination of its child */ 


Figure 9. An example program. 
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behavior of a program. This requirement 
makes monitoring program execution es¬ 
sential. To simplify the description of the 
monitoring procedure, we adopted a top- 
down approach to testing and debugging. 
(Our monitoring architecture supports a 
bottom-up approach as well.) 

Initially, the master node is monitored, 
and its execution behavior is recorded to 
identify erroneous processes in each node. 
The execution behavior of the master node 
contains all interactions among distributed 
nodes and will be compared by the user 
against the given description of the whole 
system behavior. When the processes that 
reside in the master node are believed to 
function correctly and the suspect slave 
nodes are identified, you can test and de¬ 
bug the suspect slave node in similar fash¬ 
ion. The same testing and debugging pro¬ 
cedure is applied to suspect nodes one by 
one until the erroneous processes are de¬ 
tected. The erroneous processes will then 
be examined thoroughly by applying the 
monitoring system to these processes, if 
necessary. 

Generally, the testing and debugging 
strategy for a real-time distributed com¬ 
puting system is target-system dependent. 
Based on the assumptions given in the 
section entitled “A model of real-time 
distributed computing systems,” we can 
apply the monitoring system to facilitate 
testing and debugging real-time distrib¬ 
uted systems as follows: 

(1) monitor the master node (and col¬ 
lecting trace) by using the noninva- 
sive monitoring system, 

(2) identify suspected faulty slave 
nodes and erroneous processes re¬ 
siding in the master node by exam¬ 
ining the collected traces, 

(3) monitor suspected slave nodes, if 
any, 

(4) identify erroneous processes by 
examining the traces, 

(5) repeat steps 3 and 4 until no more 
suspected nodes are left, and 

(6) examine erroneous processes one 
by one to identify bugs by using 
conventional debugging tools (if a 
user wants to focus on a suspected 
process whose details had been 
skipped). 

Through the development of real-time 
distributed computing systems, it has been 
found that many bugs do not surface until 
late in the system’s life cycle and that they 
are difficult to debug. Among such persis¬ 
tent errors, synchronization and timing 
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Figure 11. Interprocess synchroniza¬ 
tion via P/V operations. 


errors are the most difficult to detect. The 
following examples show how synchroni¬ 
zation and timing errors can be detected by 
using our approach. In this illustration, we 
assume that the faulty node is identified 
and the user is trying to locate the errone¬ 
ous process(es) on this node. 

Synchronization errors. As an ex¬ 
ample of debugging synchronization er¬ 
rors, let us consider the process synchroni¬ 
zation performed between a pair of pro¬ 
cesses, PI and P2, residing in the same 
node. We assume that communications 
between these processes are performed via 
P and V operations on a shared sema¬ 
phore X. 

In the postprocessing phase, the re¬ 
corded execution history, which contains 
accesses to a shared semaphore X that 
characterizes the process synchronization 
of the target node, is organized to form an 
event chain. The events of interest, the 
synchronization primitives in this case, are 
derived from the execution history. Mean¬ 
while, the information concerning all 
computation entities (that is, processes, 
shared objects, etc.) are also identified. 

A typical sequence of interactions be¬ 
tween processes is shown in Figure 11. By 
enforcing the P/V operation sequence to 
operate on the shared objects, we can add 
output statements to an erroneous program 
that provides additional details about the 
program behavior while preserving the 
synchronization behavior. This is not pos¬ 
sible with conventional debugging tools 
because the output statements can violate 
the timing constraints of a real-time pro¬ 


gram and yield a different synchronization 
sequence. 

Based on examination of the execution 
history, we assume the suspected synchro¬ 
nization error is located in process P2. 
Based on the information from examining 
the execution history, the user can identify 
bugs, if any, within a process by using the 
replay mechanism. 10 In the error isolation 
and correction step, the user can choose to 
examine the execution history of process 
P2 or, if necessary, choose to repeat execu¬ 
tion of the target system by enforcing the 
P/V operation sequence to perform on the 
shared object X. During the program re¬ 
play, we allow each process to reproduce 
its behavior over and over, thus providing 
opportunities for closer examinations of 
the process behavior. Any results that may 
have been ignored during previous obser¬ 
vations can always be reproduced on 
demand for closer examinations. 

Timing errors. Depending on the appli¬ 
cation and environment, timing constraints 
imposed on a real-time distributed system 
vary widely. Dasarathy gave a classifica¬ 
tion of timing constraints for a real-time 
system. 11 In general, there are two catego¬ 
ries of timing constraints: 

(1) performance constraints that set 
limits on the response time of a 
system and 

(2) behavior constraints that make 
demands on the rates at which users 
apply stimuli to the system. 

For a telephone switching system, for 
instance, the typical temporal restrictions 
are: “After the first digit has been dialed, 
the second digit shall be dialed no more 
than 20 seconds later,” or “The caller will 
receive a dial tone no later than two sec¬ 
onds after lifting the phone receiver.” To 
simplify the example, we represent the 
interesting events in a target system by the 
abstract identifications. For example, in 
case of a telephone switching system, El 
stands for lifting the phone receiver, E2 for 
sending a ring-back tone to the caller, etc. 

Let us suppose that two events, E2 and 
E3, should occur within 60 seconds after 
event El, that E3 should be delayed by at 
least 15 seconds after E2, and that it should 
occur within 30 seconds after E2. Figure 
12 gives the graphic representation of these 
requirements. In the monitoring phase, the 
time at which each event happened is re¬ 
corded. Given this information, we can 
easily examine the execution history 
against timing constraint requirements. If 
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timing violations are found, the replay 
mechanism can be used to reexamine the 
program behavior and isolate the errors. 


I n this article, we have presented a 
noninvasive hardware architecture 
for monitoring real-time distributed 
computing systems. The noninvasive hard¬ 
ware module for monitoring is being used 
to develop a testing and debugging system 
for real-time distributed computing sys¬ 
tems. Our work has focused on the moni¬ 
toring of process-level events. 

Since there is no need to modify the 
target distributed computing system, our 
approach guarantees the preservation of 
timing constraints on real-time distributed 
computing systems. Without interference 
in the execution of the target system, the 
monitoring system will not change system 
behavior and performance. A second ad¬ 
vantage is due to the flexibility of the 
programmable QCU, which can be set by 
the user to monitor different classes of 
events. 

For future research, the monitoring sys¬ 
tem will be used to support different 
abstraction-level monitoring for different 
application purposes, such as the per¬ 
formance evaluation, testing, and debug¬ 
ging of real-time distributed computing 
systems.■ 
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G raphical interfaces are becom¬ 
ing increasingly important be¬ 
cause they simplify access to 
computers for both technical and nontech¬ 
nical users. For database systems, schema 
diagrams frequently can graphically repre¬ 
sent the logical structure of a database 
during database design. We discuss here 
how a user can formulate database queries 
and updates graphically, by manipulating 
schema diagrams. 

Background and motivation. The main 
advantage of graphical schema representa¬ 
tions is that they provide a high level of 
abstraction that people can easily under¬ 
stand. We based the graphical data manipu¬ 
lation interface presented here on the en¬ 
tity-relationship (ER) model 1 because of its 
widespread use and increasing popularity. 

The basic ER model uses the concepts of 
entities, relationships, and attributes to 
represent data. Entities of the same type are 
grouped into an entity set. Figure 1 shows a 
simple ER schema diagram consisting of 
two entity sets — STUDENT and CLASS 
— and the relationship IS-TAKING. STU¬ 
DENT and CLASS are called the partici¬ 
pating entity sets for the relationship IS- 
TAKING. 

Attributes describe properties of entities 
and relationships. In Figure 1, the attributes 


Using graphical 
interfaces to formulate 
queries and updates 
makes it easier to 
interact with database 
systems for both novice 
and experienced users. 


of STUDENT are SS#, Name, and Ad¬ 
dress. 

Figure 2 is a conceptual representation 
of some data instances corresponding to 
the schema in Figure 1. Each relationship 
instance relates two entities, one from each 
of the participating entity sets. 

Our graphical interface manipulates 
schema diagrams only. The result of a 
query displays attribute values retrieved 
from the database. An update, also speci¬ 
fied graphically using schema diagrams, 
modifies the database instances when exe¬ 
cuted. 

An ER schema diagram captures many 
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of the constraints and semantics of a data¬ 
base, but some important semantic con¬ 
cepts cannot be expressed using the basic 
ER model. Many of these limitations have 
been removed by extensions to the ER 
model. 2,3 

In this article we use an extended ER 
model incorporating various forms of gen¬ 
eralization and specialization, including 
subset, union, and partition relationships. 
We call our model the extended conceptual 
entity-relationship, or ECER, model. 

Until recently, tools and methodologies 
have used the ER model and its extensions 
mainly for database design. Instead of dis¬ 
carding the graphical representation of the 
database when the design is complete, we 
wish to take advantage of the rich, high- 
level representation used in the design to 
formulate queries. 

Several advantages led to the use of ER 
diagrams for database design, such as pro¬ 
viding a high level of abstraction, display¬ 
ing database constraints and interrelation¬ 
ships, and providing easy-to-understand 
notation. The same advantages apply to the 
use of ER diagrams for query and update 
formulation. In addition, query formula¬ 
tion with schema diagrams takes advan¬ 
tage of available graphical and pointing 
devices to provide a convenient “point and 
click” interface to a database system. Thus, 
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rather than require a user to write a sym¬ 
bolic expression in a disciplined style us¬ 
ing a formal query language, we provide a 
graphical language for formulating que¬ 
ries interactively by working directly with 


a schema diagram. 

Two of the earliest query languages 
specifically designed for use with an inter¬ 
active, two-dimensional interface were 
QBE (Query-by-Example) and Cupid. 


Other graphical query interfaces followed. 
We compare our approach with those de¬ 
velopments in the sidebar “Comparison 
with other graphical entity-relationship 
interfaces.” A “Further reading” list at the 


Comparison with other graphical entity-relationship interfaces 


An important difference between our approach and the 
other query interfaces for the ER model listed in the “Further 
reading" is the formal specification of our query language, 
which provides clearly defined semantics. The graphical op¬ 
erations in our approach are based on formally defined alge¬ 
braic operations shown to be relational^ complete. 

Wong and Kuo’s article discussing the GUIDE system, for 
example, includes neither specification of the query language 
presented nor the semantics of the graphical operations. 
Rather, they concentrated on user-friendly aspects of the in¬ 
terface. In addition, the GUIDE system does not have graph¬ 
ical operations for specifying grouping, aggregate functions, 
and computations — all part of our approach, making our 
graphical query language both powerful and general. 

Elmasri and Larson described a graphical ER query lan¬ 
guage that does have a formal specification, but it uses a 
different philosophy than the one proposed here. In that ap¬ 
proach, an ER diagram is converted into a hierarchical struc¬ 
ture based on the concept of a “root entity type,” which is 
selected by the user for each individual query. Following se¬ 
lection of a root entity type, conditions for selection of root 
entities and the attributes to be retrieved are specified. Our 
approach espouses a different philosophy in that there is no 
concept of a “distinguished entity type” during query specifi¬ 
cation. Queries in our approach are specified with all entity 
types treated equally and symmetrically. This symmetric ap¬ 
proach also allows users to transform ER diagrams to inter¬ 
mediate ER diagrams as query specification evolves, and 
thus provides users with a valid ER context in which to work 
throughout the query specification process. 

Zhang’s and Mendelzon’s gql/ER interface has yet a differ¬ 
ent philosophy. It uses relational database theory to try to 
“guess” the path most likely intended by a user when specify¬ 
ing a query. This allows the user the flexibility of not having to 
specify all entity types and relationship sets needed for the 
query, but may lead to the specification of a query different 
from the intended one. Our approach does not allow the sys¬ 


tem to “guess” a most likely path. Rather, we display all pos¬ 
sible paths and let the user select the particular path needed 
for each query. Hence, the user does not unwittingly get an 
answer to a query different from the intended one. 

Another approach for user-friendly, graphical ER interfaces 
as described by Cattell is based on the concept of “browsing” 
through the database. This differs from our approach be¬ 
cause a browser is not meant to be a complete query lan¬ 
guage, only a guide that helps a user by displaying certain 
items as requested. Our approach permits browsing, but is 
not limited to browsing alone. 

In another approach, Larson and Wallick proposed a tech¬ 
nique in which syntax diagrams are displayed for specifying 
certain selection conditions and other parts of a query. The 
query is specified by going through a syntax diagram and any 
necessary additional syntax diagrams as they appear on a 
screen. Portions of the ER schema appear only when needed 
for formulation of a particular part of the query. Hence, the 
queries must be specified in a particular order defined by the 
query language. In contrast, our approach allows the user to 
specify the query in any valid order. In particular, the user 
can specify selection conditions, projection attributes, and 
connection paths in any order. 

None of the above approaches discusses the graphical 
specification of database updates, whereas our approach al¬ 
lows the specification of both retrieval and update in a unified 
and consistent manner. In addition, update requests can be 
specified so complete integrity-preserving transactions are 
constructed interactively. 

Unlike the other approaches, we provide an implementation 
model for our graphical language based on mapping a 
schema to an underlying relational database. All the graphical 
operators specified on the schema are mapped into se¬ 
quences of relational operators that can be optimized and 
executed by a relational DBMS. Hence, the proposed query 
language can be easily implemented as a front end to a rela¬ 
tional DBMS. 
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Figure 3. A sample ECER schema diagram. 


end of the article provides references to 
pertinent literature on graphical query 
languages. 

Approach. Since the ER and ECER data 
models have natural, graphical representa¬ 
tions, we chose to display the database 
schema and to provide schema-manipula¬ 
tion operators to formulate queries graphi¬ 
cally. From the end user’s point of view, 
the data in a stored database is manipulated 
in a manner consistent with changes made 
to the schema diagram. The schema-ma¬ 
nipulation operators correspond to formal 
algebraic operators defined for the ECER 
model. However, the end user does not 
need to be aware of the underlying formal¬ 
ism. The main function of the formalism is 
to establish the properties of the schema- 
manipulation operators and to show that 
the ECER interface can be implemented 


efficiently. 

We assume that the entity and relation¬ 
ship sets of the ECER model are unambi¬ 
guously mapped into relations of an under¬ 
lying stored relational database. To in¬ 
clude computations, we have augmented 
the set of relational operators so that it also 
contains a computation operator that sup¬ 
ports simple arithmetic operations, aggre¬ 
gate built-in functions, and grouping. 4 The 
graphical operators specified by a user are 
transformed into sequences of relational 
operators for processing. Hence, our ap¬ 
proach can be used to implement a front- 
end graphical interface to a relational 
DBMS. Since the sequence of relational 
operators is not executed until the query is 
completely specified, we can perform 
query optimization before the query is 
executed. An end user never needs to be 
concerned with the underlying relational 


operators—the query is specified solely in 
terms of the graphic representations of the 
ECER model. 

Our graphical update operations check 
and enforce integrity constraints specified 
in an ECER diagram. To preserve integ¬ 
rity, some updates may propagate auto¬ 
matically. When automatic propagation is 
not feasible, the system can interact with 
an end user by providing a list of additional 
update operations that could accompany 
the original update request. These update 
operations can be mandatory or optional. 
The system accumulates user requests, but 
delays their execution until a complete 
sequence of integrity-preserving update 
operations is specified. This sequence of 
operations can then be executed as an 
atomic database transaction. End users can 
either execute predefined update transac¬ 
tions or interactively create and execute an 
integrity-preserving transaction. 

We previously proposed a graphical 
query language for Chen’s basic ER 
model 5,6 and have extended it to include 
computations. 4 We also proposed a graph¬ 
ical query language for the entity-cate¬ 
gory-relationship model 7 and have consid¬ 
ered update operations in this context. 8 
Here we introduce the ECER model and 
bring together various aspects of our previ¬ 
ous work to present a unified data manipu¬ 
lation language that includes both graph¬ 
ical query formulation and graphical up¬ 
date specification. 

Conceptual schema 
diagrams 

Using the ECER model, a database 
schema can be represented graphically as 
an ECER diagram. The sample diagram 
shown in Figure 3 represents a simple 
university database. We use this example 
throughout to illustrate various concepts. 

In Figure 3, entity sets are represented 
by rectangular boxes. Each entity set in the 
schema represents a set of entities in the 
database that are of the same type and share 
some common properties or roles. An indi¬ 
vidual entity is identified by a unique sur¬ 
rogate key value 9 that serves to distinguish 
it from other entities in the database. An 
example of an entity set is FACULTY, 
which represents all faculty members 
known to the database. 

A relationship set in an ECER diagram 
is represented by a diamond-shaped box. It 
represents a set of relationship instances, 
where each instance relates one entity from 
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each of the participating entity sets. For 
example, the relationship set IS-TAKING 
in Figures 1 and 2 represents STUDENT- 
CLASS pairs with student s currently tak¬ 
ing class c. A relationship instance must be 
uniquely identifiable by the participating 
entity instances. 

Participation constraints on relationship 
sets are represented by an integer pair 
(mirr.max) on each participating entity set. 
The value min gives the minimum number 
of relationship instances in which an entity 
of the participating entity set must be in¬ 
cluded, while max gives the maximum 
number. A max=* indicates no constraint 
on the maximum number. For example, in 
the OWNS relationship (see Figure 3), a 
VEHICLE entity participates exactly once 
(1:1) in the relationship, which means that 
a vehicle must be related to exactly one 
owner, whereas a VEHICLE-OWNER 
entity participates one or more times (1:*), 
which means that a vehicle owner owns at 
least one vehicle, but possibly more. 

The participation constraints used in our 
ECER model are more general than the 
traditional cardinality constraints used 
with basic ER diagrams to designate 
whether relationship sets are one-one, one- 
many, or many-many. For binary relation¬ 
ship sets, cardinality constraints can be 
derived from participation constraints. 
Additional information, such as whether a 
relationship is total or partial, can also be 
derived from the (min'.max) constraints. 
Since participation constraints are used to 
ensure the correctness of update opera¬ 
tions, we will only display these con¬ 
straints on ECER schema diagrams during 
update specification. The constraints will 
not be displayed during graphical query 
formulation. 

One of the basic concepts recognized in 
semantic data modeling is generalization/ 
specialization. Generalization/specializa¬ 
tion in the ECER model defines super¬ 
class/subclass relationships between en¬ 
tity sets. Each entity in a subclass entity set 
must also be an entity in the superclass 
entity set. This has also been called an IS- 
A relationship from the subclass (speciali¬ 
zation entity set) to the superclass (gener¬ 
alization entity set). For example, in Fig¬ 
ure 3, GRAD-STUDENT is a specializa¬ 
tion of STUDENT, thus each graduate 
student is also a student. Conversely, 
STUDENT is a generalization of GRAD- 
STUDENT, thus a subset of the students 
are graduate students. 

In general, the recognized types of gen¬ 
eralization/specialization differ in the 
constraints placed on participating entity 


sets. The three types discussed here fol¬ 
low: 

Type 1 : Involves exactly two entity sets, 
with one a subset of the other. In an ECER 
diagram we denote this by placing a subset 
symbol on the arc connecting the two en¬ 
tity sets. For example, in Figure 3 GRAD- 
STUDENT is a specialization of STU¬ 
DENT and VEHICLE-OWNER is a spe¬ 
cialization of PERSON. 

Type 2: Involves one generalization 
entity set A and any number of specializa¬ 
tion entity sets B V B V ...,B„, with A = B t u 
B 2 u ... u B n . In an ECER diagram we 
denote this by connecting entity set A to 


one side of a circled union symbol and by 
joining arcs emanating from each entity set 
B. (1 < i < n) and connecting them to the 
other side of the circled-union symbol. In 
Figure 3 the union of FACULTY and 
STUDENT is PERSON, thus every person 
represented in the database is either a fac¬ 
ulty member or a student or both. 

Type 3: As in Type 2, involves one 
generalization entity set A and any number 
of specialization entity sets B x , B v .... B n , 
but here the entity sets B { through B n form 
a partition of the entity set A (that is, the 
S.’s are disjoint and their union is A). In an 
ECER diagram we denote this in the same 
way as we denote a Type 2 union generali- 


Formal definition of the ECER model 

The formal definition we present assumes an underlying relational database 
stores the data represented by an ECER schema diagram. Relational algebra ex¬ 
pressions are used in the formal model to specify the mapping between the 
ECER schema and the underlying database. In the relational database, each en¬ 
tity in the ECER model is identified by a unique surrogate value in the database. 

Let U be a set of attribute names and V be a set of names of entity sets and re¬ 
lationship sets. An entity-set descriptor is a triple ( N,A,X ), where N is an element 
of V, A is a (possibly empty) subset of U, and Xis a relational algebra expres¬ 
sion. The attributes in A include only directly associated attributes; they do not 
include inherited attributes. The expression Xis specified on the underlying rela¬ 
tional database. When executed, X yields a set of tuples representing all entities 
that belong to the entity set N. Each tuple represents one entity instance and 
consists of a value for each attribute in A plus a value for a surrogate-key attri¬ 
bute, which represents the entity itself. 

In Figure 3, for example, (PERSON, {SS#, Name}, person) is the descriptor for 
the PERSON entity set, where person is the name of the underlying relation. The 
relation person has three attributes, namely, PERSONJD for the surrogate-key 
attribute, plus SS# and Name. 

A relationship-set descriptor is a four-tuple (N,A,E,X), where N is an element of 
V, A is a (possibly empty) subset of U, E is a set of two or more entity set de¬ 
scriptors with attached participation constraints, and Xis a relational algebra ex¬ 
pression. The expression Xis specified on the underlying relational database. 
When executed, X yields a set of tuples representing all relationship instances 
that belong to the relationship set N. Each tuple represents one such relationship 
instance and consists of a value for each attribute in A plus a surrogate value for 
an entity from each entity set participating in the relationship set. We assume 
that the set of entity values participating in a relationship instance is sufficient to 
identify the relationship instance. 

In Figure 3, for example, (IS-TAKING, {No-of-Repetitions}, (STUDENT(0:*), 
CLASS(0:*)}, is-taking) is the descriptor for the IS-TAKING relationship set. The 
underlying relation is-taking has attributes STUDENTJD, CLASSJD, and No-of- 
Repetitions. 

A generalization/specialization descriptor s a three-tuple ( G,TYPE,S ), where G 
is the entity-set descriptor for the generalization and S is the set of entity-set de¬ 
scriptors for the specialization entity set(s). TYPE is one of the symbols 3, ©, or 
©. We require 6 c S for all types and that the cardinality of S is one for the 3 
type and greater than one for the other types. In Figure 3, we have four ex¬ 
amples: (STUDENT, 3, {GRAD-STUDENT}), (PERSON, 3, {VEHICLE- 
OWNER}), (PERSON, ©, {FACULTY, STUDENT}), and (VEHICLE, ©, {MO¬ 
TORCYCLE, CAR}). 

An ECER schema is a triple (E,R,G/S), where E is a set of entity-set 
descriptors, R is a set of relationship-set descriptors, and G/S is a set of gener¬ 
alization/specialization descriptors. 
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zation/specialization except that we use a 
circled-plus symbol rather than a circled- 
union symbol. In Figure 3 MOTOR¬ 
CYCLE and CAR constitute a partition of 
VEHICLE, thus every vehicle is either a 
motorcycle or a car, but not both. 

Other possible constraints on speciali¬ 
zation/generalization exist, but the above 
three are sufficient to illustrate our ideas. 

Both entity sets and relationship sets 
may have attributes. We represent attri¬ 
butes by their names and attach them to 
their respective entity or relationship sets 
by an arc. The attributes of CLASS, for 
example, are Class-ID#, Course#, and 
Section#. This denotes that each class en¬ 


tity has a class ID, a course number, and a 
section number. Specialization entity sets 
inherit attributes from generalization en¬ 
tity sets. Thus, Name and SS# (which are 
attributes of PERSON) are also attributes 
of FACULTY and STUDENT and, by tran¬ 
sitivity, of GRAD-STUDENT. GRAD- 
STUDENT also has the attribute Address, 
inherited from STUDENT, but Undergrad- 
School is an attribute of GRAD-STU¬ 
DENT only. 

We can formally define an ECER model 
as shown in the sidebar on page 29. The 
model is particularly useful for formally 
defining diagram manipulation operators 
and for formally stating properties of an 
ECER system. 


Data retrieval 
operators 

As mentioned earlier, our operators 
manipulate a graphical schema diagram. 
The graphical operators are translated into 
operations on the underlying stored data¬ 
base. In this article we assume a mapping 
that provides a one-to-one correspondence 
between the entity and relationship sets 
and the underlying relations (see “Implem¬ 
entation model” below). Other (possibly 
more efficient) mappings can be defined. 

A possible screen layout for the graph¬ 
ical interface lists the applicable operators 
at the top of the screen, reserves an area at 
the bottom for messages between the sys¬ 
tem and user, and displays the current 
schema diagram in the remaining area. 
Large diagrams can be displayed using 
windowing and zooming. A user manipu¬ 
lates a diagram by pointing to an operator 
and then to items in the diagram as needed. 
Depending on the operator, the user may 
also enter text in the message area. After 
each operator invocation, the diagram is 
modified and a new diagram is displayed. 
The current diagram displayed on the 
screen corresponds to a view of the data 
and can be interpreted as a query. 

This approach to query formulation has 
the following advantages: 

(1) Diagrams that represent a view of 
the database schema are displayed and can 
be manipulated interactively. 

(2) Query formulation is flexible. A 
query can be formulated in many different 
ways, since the order in which the diagram 
manipulating operators are invoked is of¬ 
ten immaterial. 

(3) The user always has a convenient 
frame of reference. The current diagram 
reflects the current status of query formu¬ 
lation, and it is possible to interpret each 
diagram as a query. 

(4) An “undo” operator to reverse pre¬ 
vious operations can be easily imple¬ 
mented by keeping copies of ECER sche¬ 
mas on a stack. 

(5) Immediate feedback is provided 
whenever an operator is invalid in the 
current context. 

We now present examples of the graph¬ 
ical operations that can be used during the 
query specification process. These opera¬ 
tors are introduced here informally. A 
sample formal definition appears in the 
sidebar “Formal definitions for data re¬ 
trieval operators.” 


Formal definitions for data retrieval 
operators 

Each operator is defined by providing the operator’s name, its argument list, 
and its semantics. Procedural notation is used to describe the semantics. Most 
operators are partial in that they are valid only if certain preconditions are satis¬ 
fied As an example, we present a formal definition for the operator Remove. 

Remove(w) 

Given an object w, which can be either an entity set e, a relationship set r, or 
an attribute-object-set pair (a,z), where z is either an entity set or a relationship 
set, the Remove operator deletes w from the ECER model. In some cases, the 
deletion propagates. 

Preconditions: 

1. if w is an entity-set descriptor, we E 

2. if w is a relationship-set descriptor, we R 

3. if w is an attribute-object-set pair (a,z), 

a. w.z s E or w.z e R 

b. w.a e w.z.A 

Action: 

if w is a entity set descriptor 
/* Remove subclasses of w. 7 
for each generalization/specialization g e G/S 
if w=g.G 
for each se g.S 
Remove(s) 

/* Remove each relationship set associated with w. 7 
for each relationship re R 
if win r.E 
Remove(r) 

£<- E-{wj 

if w is a relationship set descriptor 
R<r- R-{w\ 

if wis an attribute-object-set pair (a,z) 
w.z.A <- w.z.A - {a} 
w.z.X<- n w!t w.z.X 
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Figure 4. The ECER schema diagram after applying the Remove operator to 
STUDENT. 


Restrict. Restrict imposes a Boolean 
condition over the attributes of an entity or 
relationship set to restrict the instances in 
the set to those that satisfy the condition. 

As an example, suppose the user wants 
to limit the vehicles in the VEHICLE en¬ 
tity set to those that have more than one 
ticket. This can be done by selecting the 
Restrict operator, then the attribute No-of- 
Tickets, and then entering “> 1.” After this 
restrict operation, the diagram is the same 
as before except that the condition “No-of- 
Tickets > 1” is displayed inside the VE¬ 
HICLE entity set rectangle. 

Similarly, to restrict the IS_TAKING 
relationship set to only those not repeating 
classes, a user can select the Restrict op¬ 
erator, point at the argument attribute No- 
of-Repetitions, and enter “= 0.” 

Remove. This operator can be used to 


remove unneeded entity sets, relationship 
sets, and attributes. When applied to a 
relationship set, the operator removes the 
relationship set and its attributes (if any) 
from the diagram. When applied to an 
entity set. Remove not only removes the 
entity set, but also all relationship sets in 
which the entity set participates as well as 
all specialization subclasses of the deleted 
entity set. Removal of subclasses may 
cause further removal of relationship sets 
and other subclasses. When directly ap¬ 
plied to an entity set that is a subclass, 
however. Remove does not delete the su¬ 
perclass. Direct removal of a subclass can 
also change the type of the subclass rela¬ 
tionship for an entity set remaining in the 
diagram. 

For example, let us assume that the cur¬ 
rent diagram is as shown in Figure 3. If a 
user selects the Remove operator and then 


the STUDENT entity set, the STUDENT 
entity set is removed along with Address, 
its attribute. Since STUDENT participates 
in the IS-TAKING relationship set, IS- 
TAKING is also removed. Since the 
GRAD-STUDENT entity set is a speciali¬ 
zation of STUDENT, it is also removed 
along with its attribute Undergrad-School. 
Because of the removal of GRAD-STU¬ 
DENT, the deletion propagates to the rela¬ 
tionship set ADVISES, which is also re¬ 
moved. When the current diagram is redis¬ 
played, STUDENT, GRAD-STUDENT, 
ADVISES, and IS-TAKING and their at¬ 
tributes are removed. Furthermore, since 
the FACULTY entity set is now the only 
specialization of PERSON, the union gen¬ 
eralization/specialization is converted into 
a subset generalization/specialization with 
PERSON as the superclass and FACULTY 
as the subclass. The resulting diagram 
appears in Figure 4. 

Note that even when all attributes of an 
entity or relationship set are removed, 
individual entities and relationship in¬ 
stances retain their identity. This happens 
because of our use of surrogate values to 
identify individual entities and our con¬ 
straint that the set of entities participating 
in a relationship instance be sufficient to 
identify the relationship instance. These 
attribute-less entities and relationship in¬ 
stances are useful in queries in which we 
are interested only in the existence of the 
instance. For example, we might be inter¬ 
ested in the classes taught by a particular 
student’s advisor, but not in the attributes 
of the advisor. 

Display. This operator translates a final 
diagram into a sequence of operations that 
can be executed on the underlying stored 
database. The execution of these opera¬ 
tions will yield the result of the query, 
which can then be presented to the user. 
Display joins relations corresponding to 
remaining entity and relationship sets and 
projects on the remaining attributes. Only 
those entities remaining after the applica¬ 
tion of any Restrict operators are involved 
in the joins. 

As an example, suppose we want to 
formulate a query to retrieve the names and 
addresses of all students who have more 
than one parking ticket. Starting from the 
diagram in Figure 3, we begin by removing 
all unnecessary entity and relationship sets 
from the diagram by graphically choosing 
the Remove operator and pointing at the 
FACULTY, CLASS, GRAD-STUDENT, 
MOTORCYCLE, and CAR entity sets. 
Relationship sets involving the deleted 
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Figure 5. An intermediate ECER diagram during the specification of the query 
“Retrieve the names and addresses of all students who have more than one park¬ 
ing ticket.” 



Figure 6. The final ECER diagram cor¬ 
responding to the query “Retrieve the 
names and addresses of all students who 
have more than one parking ticket.” 

entity sets (IS-TAKING, IS-TEACHING, 
and ADVISES) are automatically removed 
from the diagram, as are attributes of all 
removed entity and relationship sets. Fig¬ 
ure 5 shows the diagram corresponding to 
the current state of the query formulation 
process. (Note that, in query mode, partici¬ 
pation constraints are neither used nor 
displayed.) We next restrict VEHICLE to 
those with more than one parking ticket. 
The selection can be specified by invoking 
the Restrict operator, choosing the No-of- 


Tickets attribute, and entering “> 1.” Fi¬ 
nally, we can specify the attributes of inter¬ 
est by graphically deleting all but those to 
be displayed. Figure 6 shows the final 
reduced diagram, which represents the 
query. 

When the Display operator is invoked, 
the relations corresponding to the entity 
and relationship sets remaining in the 
query diagram are joined. During the join, 
only those tuples corresponding to stu¬ 
dents who are vehicle owners remain. The 
join with the VEHICLE relation (through 
OWNS) will leave only tuples satisfying 
the explicitly imposed Restrict condition 
“No-of-Tickets > 1.” Hence, the query 
result includes only students who own 
vehicles with more than one ticket. As 
specified in the diagram of Figure 6, only 
the Name and Address attributes are re¬ 
trieved. The result of the query can be 
displayed as in Figure 7. 

Additional ECER operators. We have 
defined other operations including Keep, 
Union, Set-Difference, Intersection, 
Rename, Duplicate, and Create-Relation- 
ship for the ER model. 5 Some of these 
operators are merely convenient, but oth¬ 
ers add power to the language. Keep, for 
example, is more convenient than Remove 
when only a small part of a large diagram 
is of interest. Duplicate adds power and is 
necessary to formulate queries that involve 
multiple and distinct references to the same 
entity set, such as “Find the classmates of 
Nancy Adams.” 

A minimal set of operators has been 


identified and shown to have the expres¬ 
sive power of Codd’s relational algebra. 10 
Similar operations can be defined for the 
ECER model. 


Computation 

operators 

Computations in the ECER model have 
two forms. Compute-Attribute is used to 
compute values for attributes of existing 
entity or relationship sets, and Compute- 
Entity-Set is used to specify and compute 
values for new entity sets. Computed attri¬ 
butes and entity sets are only specified for 
the use of a particular query and are not 
stored in the database. 

Compute-Attribute adds a new attribute 
A to an entity set or a relationship set and 
specifies the formula to be used to compute 
the values of A. A user invokes this opera¬ 
tor graphically by pointing either at an 
entity set or at a relationship set and filling 
in the template “<attribute> := <expres- • 
sion>.” 

As an example, let us compute the basic 
life-insurance benefit for a faculty mem¬ 
ber, assuming we know that the benefit 
amount is twice the faculty member’s cur¬ 
rent salary. We can obtain the amount by 
selecting the Compute-Attribute operator, 
pointing at the FACULTY entity set, and 
entering “Basic-Life-Amount := 2*Sal- 
ary.” The computed Basic-Life-Amount 
attribute is added as an additional attribute 
for FACULTY. 

Compute-Entity-Set specifies a new 
entity set by applying an aggregate opera¬ 
tor. When this operator is invoked, a user is 
requested to specify the new entity-set 
name, the name(s) of its key attribute(s) 
(which are the grouping attribute(s) for the 
aggregate operator), the name of the com¬ 
puted attribute (which may or may not be 
one of the key attribute(s)), and the aggre¬ 
gate operator. 

For example, to retrieve the average 
faculty salary for each department, we 
select Compute-Entity-Set and enter the 
new entity-set name DEPT-AVG-SAL¬ 
ARY, the grouping attribute Department, 
the computed attribute Avg-Departmen- 
tal-Salary, and the aggregate operator Avg. 
The resulting diagram has the new stand¬ 
alone entity set DEPT-AVG-SALARY 
with two attributes, Department and Avg- 
Departmental-Salary. When the Display 
operator is invoked, the query is executed 
and the result of the query will show an 
entity instance in DEPT-AVG-SALARY 
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Name 

Address 

John Smith 
Alicia Zelaya 
GeneTardelli 

3426 Bellaire Blvd. 

253 S. Gessner Rd. 

6354 Beechnut St. 


PERSON - SS# 
SS#= 123-45-6789 - Name 


„ Total-No-of-Tickets 


Figure 7. Possible result for the query of Figure 6. 


Figure 8. The ECER diagram corresponding to the query “Get 
the total number of tickets and total fine for John Jones.” 


for each department with the department 
name and an average salary value. 

We can use the computation operators 
and the data-retrieval operators together to 
formulate queries. For example, suppose 
we want to determine how many tickets 
John Jones, whose SS# is 123-45-6789, 
has for all of his vehicles and how much he 
owes all together for these parking tickets. 
We assume that each parking ticket carries 
a $25 fine. To graphically specify this 
query, we can first restrict the PERSON 
entity set by selecting the Restrict opera¬ 
tor, pointing at SS#, and entering “= 123- 
45-6789.” We then select the Compute- 
Attribute operation, point at PERSON, and 
enter “Total-No-of-Tickets := SUM(No- 
of-Tickets).” We next select the Compute- 
Attribute operator again, point at PER¬ 
SON, and enter “Total-Fine := 25*Total- 
No-of-Tickets.” Finally, we remove un¬ 
wanted attributes and unnecessary entity 
and relationship sets by selecting the Re¬ 
move operator and pointing at FACULTY, 
STUDENT, CLASS, VEHICLE, and 
VEHICLE-OWNER. The final diagram 
for this query is shown in Figure 8. The 
query can be now executed by invoking the 
Display operator, which generates the 
(optimized) query expression on the stored 
database. 


Update operators 

In this section we describe some of the 
operations that can be used to alter data 
stored in the database. An ECER update 
transaction may consist of several opera¬ 
tions whose cumulative effect transforms a 
database from one consistent state into 
another. A main feature of these update 
operations is that they propagate automati¬ 
cally, according to the ECER model se¬ 
mantics, to preserve the semantic integrity 
of the database. The semantic concepts 
that drive the propagation are intuitive and 
are similar to the ideas behind the Codasyl 
Database Task Group update facilities. 11 

The propagation mechanisms can be 
divided into two types. The first type. 


mandatory propagation, requires that an 
update operation be accompanied by other 
complementary operations. For example, 
if an instance of entity set STUDENT is 
removed, the related instances of the re¬ 
lationship set IS-TAKING must also be 
removed, as well as any corresponding 
entity instance in GRAD-STUDENT and 
associated relationship instances in 
ADVISES. 

Participation constraints may also re¬ 
quire related updates. Deletion of a VE¬ 
HICLE entity instance that is the only 
vehicle owned by a particular person, for 
example, would result in the violation of 
participation constraints because a vehicle 
owner must own at least one vehicle. 
Hence, this update request must be ex¬ 
tended by deleting the VEHICLE- 
OWNER. 

The second type of propagation is op¬ 
tional. If we insert an entity instance, we 
may not have to also insert the entity into 
associated relationship sets and sub¬ 
classes, but we might wish to do so. For 
example, when inserting a new student we 
might also wish to record that the student is 
a graduate student. Updates can continue 
to propagate in this way. A sequence of 
optional propagating updates can be termi¬ 
nated by the user at any point. 

Our update operators are executed in 
two phases. In the first phase the update 
specifications are accumulated into an 
update transaction. In the second phase 
(delayed execution) the transaction is exe¬ 
cuted, but only if guaranteed to leave the 
database in a consistent state. If a violation 
occurs during the first phase, an update 
transaction can be aborted by simply dis¬ 
carding the accumulated update action 
specifications. 

The following update operators are de¬ 
fined in our model: Insert-Entity, Insert- 
Relationship, Delete-Entity, Delete-Rela¬ 
tionship, and Modify-Attribute. These 
operators insert, delete, and modify entity 
and relationship instances and thus alter 
the data stored in the database. 

For our interface we assume that the 
update operators Insert, Delete, and Mod¬ 


ify are listed on the screen along with the 
query operators described above. To do an 
insertion, a user selects Insert and points at 
an entity or relationship set. The system 
requests necessary information and guides 
the user through the insertion. For dele¬ 
tion, the user selects Delete, points at an 
entity or relationship set, and enters an 
expression to identify the objects to be 
deleted. For modification, the user selects 
Modify, points at the attribute to be modi¬ 
fied, and enters the new value and an ex¬ 
pression to select the objects to be modi¬ 
fied. Selection expressions for Modify are 
similar to the expressions of the Restrict 
operator. An example is the expression 
“is(GRAD-STUDENT) and (No-of-Tick- 
ets > 10),” which can be applied to PER¬ 
SON to select graduate students who have 
more than 10 tickets. 

Consider a database operation for the 
registration of a new graduate student, 
Alicia Adams. The user selects Insert and 
points at GRAD-STUDENT. The system 
then asks for the value of the attribute 
Undergrad-School and the inherited attri¬ 
butes SS#, Name, and Address. Some of 
the attributes may be designated manda¬ 
tory, so values must be provided for these 
attributes. For nonmandatory attributes, 
the user does not have to enter a value, 
since NULL is allowed. 

Once the attribute values are entered, 
mandatory processing for Insert-Entity is 
complete, but there may be some optional 
updates. The system asks whether Alicia is 
registered to take classes. Assuming the 
answer is “no,” propagation along this path 
ceases. Next, the system asks whether 
Alicia is a vehicle owner. Assuming the 
answer is “yes,” the system requests a 
value for Drivers-License#. Since every 
vehicle owner must own at least one ve¬ 
hicle, the insertion must now propagate to 
the OWNS relationship set. Thus, for each 
vehicle the system requests a Permit#, 
Registration#, No-of-Tickets, type of ve¬ 
hicle (car or motorcycle), and, if the ve¬ 
hicle is a car, the assigned parking lot 
number. Propagation along this path then 
terminates. Since Alicia is a graduate stu- 
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vehicle ( VEHICLE-ID . Permit#, Registration#, No-of-Tickets) 


car ( CAR-ID . Parking-Lot#) 

owns ( VEHICLE-ID . VEHICLE-OWNER-ID) 

vehicle-owner ( VEHICLE-OWNER-ID . Drivers-License#) 

person ( PERSON-ID . SS#, Name) 

faculty ( FACULTY-ID . Department, Office, Salary, Rank) 

student ( STUDENT-ID . Address) 

grad-student ( GRAD-STUDENT-ID . Undergrad-School) 

advises (FACULTY-ID, GRAD-STUDENT-ID 1 

class ( CLASS-ID . Class-ID#, Course#, Section#) 

is-teaching (FACULTY-ID, CLASS-ID . Times-Taught) 

is-taking (STUDENT-ID. CLASS-ID . No-of-Repetitions) 


Figure 9. A relational database schema corresponding to the ECER schema of 
Figure 3. 


dent, the system asks if she has been as¬ 
signed a faculty advisor. Assuming the 
answer is “no,” propagation along this path 
ceases. Since there are no more paths to 
follow, transaction specification is com¬ 
pleted. 

These actions form a complete, semanti¬ 
cally correct database transaction that, 
when executed atomically on a consistent 
database, transforms the database into 
another consistent state. 

Implementation model 

ECER operators can be implemented in 
several ways. If the underlying database 
management system supports a high-level 
data manipulation language (DML) corre¬ 
sponding to the semantic data model (for 
example, Gordas 12 for the ECR model), the 
ECER operators can be directly translated 
into equivalent semantic DML queries. An 
alternative and more general solution is to 
map the graphically invoked ECER opera¬ 
tors into equivalent algebraic operations 
on the corresponding relational database. 
We assumed this approach in our defini¬ 
tion of operator semantics and discuss it 
below. 

, Each ECER operator corresponds to a 
sequence of operations that maps a set of 
relation instances into another set of rela¬ 
tion instances. The initial instance is the 
current database state. For our example the 
initial set of relations corresponding to the 
ECER diagram in Figure 3 contains the 
relations faculty, person, vehicle-owner, 
vehicle, motorcycle, car, student, grad- 
student, class, is-teaching, is-taking, ad¬ 
vises, and owns (see Figure 9). 


Of course, actually manipulating the 
stored relation instances as the query is 
formulated would be inefficient. Instead, 
we can delay the evaluation of the rela¬ 
tional algebra expressions by accumulat¬ 
ing the appropriate information in the en¬ 
tity and relationship set descriptors (see 
the sidebar, “Formal definition of the 
ECER model”) as the diagram is manipu¬ 
lated. For example, if the operator Restrict 
is applied to FACULTY to limit it to fac¬ 
ulty members in the Computer Science 
Department, the X component for FAC¬ 
ULTY, which is initially faculty, is re¬ 
placed by a Depar , m ^ CompuurScim ,faculty. 

To produce a single table for a query 
specified by an ECER diagram, we join 
relations corresponding to remaining en¬ 
tity and relationship sets using equi-join 
over the surrogate keys of connected ob¬ 
jects and then project on the attributes 
remaining in the diagram. This expression, 
of course, can be optimized before execu- 

A prototype graphical data manipula¬ 
tion language based on the approach de¬ 
scribed here has been implemented on an 
Apple Macintosh computer. 6 The current 
status of the implementation includes a 
graphical interface for the query-retrieval 
operators Remove, Restrict, and Display. 
The implementation also includes the 
operators Combine, Relationship-Set- 
Union, Relationship-Set-Intersection, Re¬ 
name, and Add-Relationship-Set, not dis¬ 
cussed here. In addition, facilities to move 
diagram elements and to undo the previous 
operation are provided. In our implemen¬ 
tation, the relational database queries are 
generated in SQL rather than in relational 
algebra. 


T he graphical interface presented 
here for querying and updating 
databases uses the ECER model, 
which is based on the popular entity-rela¬ 
tionship model but has additional semantic 
modeling concepts. Our approach is to 
define graphical manipulation operators 
that allow queries to be specified by ma¬ 
nipulating schema diagrams. Diagrams are 
transformed until they represent a desired 
user query. 

To specify and implement update opera¬ 
tions for the ECER model, we define 
graphical operators that allow updates to 
be specified through schema diagrams. 
The system may require that an update 
request be complemented with a specifica¬ 
tion of the other update operations required 
by the integrity constraints of the ECER 
schema. The system can also suggest op¬ 
tional but related update operations. As a 
result, a user specifies only complete in¬ 
tegrity-preserving transactions in an inter¬ 
action with the system. 

To efficiently implement the operators, 
we can define them as functions that oper¬ 
ate on an abstract data model. Based on the 
definition of these operators, the result of 
formulating a query can be expressed in a 
relational query language. This allows for 
an efficient implementation because a re¬ 
lational expression generated as a result of 
graphically manipulating a diagram can be 
optimized, using standard techniques, be¬ 
fore it is executed. Thus, the proposed 
graphical interface can be implemented as 
a front-end to an existing relational data¬ 
base system. Users need not be aware of 
the underlying transformations and can 
concentrate on high-level specifications 
for queries and updates.B 
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applied research to expand the use of parallel 
processing technology. As the institute 
grows, itwill address other areas of advanced 
computing as well. Industry is involved in 
shaping the direction of research and 
facilitating its rapid transfer out of the labs 
and into businesses. The majority of 
researchers are from public and private 
universities in Oregon. Combined federal/ 
state/private commitments are in hand to 
support multi-year research projects. OACIS 
is actively recruiting for: DIRECTOR/CHIEF 
SCIENTIST. 

Principal Responsibilities: 

Technical leadership of world-class 
research, development and technology 
transfer institute in advanced computing 
with special focus on parallel processing. 
OACIS is a major interdisciplinary research 
institute having active involvement with 
several universities and industrial affiliates. 
Candidate must be able to entrepreneurially 
leverage the resources of OACIS through 
cooperative partnering with these 
organizations. 

Building and maintaining close, formal 
linkages with faculty from several Oregon 
universities who wi 11 direct their appropriate 
research interest through OACIS. Also, 
establishing a strong network of support and 
interaction with appropriate high- 
technology industry and users in Oregon 
and throughoutthe United States. Academic 
joint appointment at one (or more) of the 
affiliated Oregon universities is available 
and desirable. 

Minimum Qualifications: 

PhD degree or equivalent in computer 
science/engineering or related field. Ten 
years experience, with emphasis in the 
parallel processing field. Relevant 
experience includes leadership of a research 
team, with a track record of journal 
publications; receipt of grants from 
government and industry; scientific 
conference participation; filling leadership 
roles in international professional societies; 
and holding positions of major technical 
responsibility. This experience should 
(preferably) include responsibilities for 
budget, personnel, proposal preparation and 
long-term planning. 

Academic ana industrial experience 
required. Participation in, or affiliate 
representation with a university/industry 
cooperative research center is especially 
important. Needs to have direct exposure to 
applications driven approach to conducting 
research. Preference will be given to 
cand idates who have successfu I ly transferred 
technology from research organizations such 
as university, government or industrial 
laboratory to commercial products. 

Please send resumes, including 
rofessional references, to: Search 
ommittee, OACIS; 19500 NW Gibbs 
Dr.; Beaverton, Oregon 97006-6907. 
OACIS is an affirmative action/equal 
opportunity employer. 
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browsing systems, which allow users to display 
actual data instances during query formulation 
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users to retrieve relevant data by referencing 
both schema objects and actual data from the 
database. 
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Researchers 

Network Systems and Services 


Bellcore’s Applied Research Laboratory is an 
interdisciplinary systems research organization, 
primarily concerned with basic and applied 
research in areas relevant to the Regional Bell 
Companies. The Network Systems and Services 
Research Laboratory concentrates on creating 
the technological base for public communica¬ 
tions in the 21st century. We have opportunities 
for Researchers in the following areas: 

The Multimedia Communications Research 
Division explores ways information technology 
can provide future communications services and 
information access. Research projects explore 
ways to enhance human communication through 
the use of multimedia information. Applicants 
must be determined to see these ideas through 
to actual demonstrations. Areas of immediate 
interest are: multimedia communications (voice, 
video, text, pictures), information search and 
retrieval, and real-time systems. 

The Network Systems Research Division 
primarily investigates highly reliable distributed 
real-time control systems for telecommunications 
applications. These large systems have special 
requirements for high throughput, extreme relia¬ 
bility, and short response time. Candidates must 
be good at problem definition, and eager to work 
on real problems. Areas of principle concern are: 
global naming and network addressing schemes, 
techniques to reduce software complexity, formal 
methods, extensible software, network manage¬ 
ment, and distributed systems. 

The Systems Integration Research Division 

explores high speed network architectures, pro¬ 
tocols, and prototypes. Such high-performance 
networks will support the multimedia services 
and applications of the future, including digital 
TV. Needed are people with the necessary tech¬ 
nical expertise to realize this leading edge 
research. Areas of current emphasis are: 
Broadband ISDN; lightwave LANS and MANS; 
as well as communication management and data 
transmission protocols. 

The Packet Communications Research Divi¬ 
sion conducts research into large scale, high 
speed, packet switched networks. The current 
focus includes research into the VLSI devices 
necessary to build high speed packet switches, 
the architectures necessary to build large net¬ 
works from these devices, and the protocols 
necessary to derive high speed data 


communications services from these networks. 
Current areas of investigation include: switching, 
computer, and VLSI architectures; high speed 
digital systems; internetworking; congestion con¬ 
trol; transport, routing, and management pro¬ 
tocols for computer networks. 

Candidates should have a PhD in either Com¬ 
puter Science or Electrical Engineering, or have 
equivalent experience/education and demon¬ 
strated research skills in one or more of the fol¬ 
lowing areas: 

• Human computer interface design/implementation 

• User interface implementation tools (UIMS) 

• Interactive computer graphics 

• Image processing 

• Communications and information security 

• Heterogenous databases and advanced 
query techniques 

• Fault tolerance 

• Parallel and/or distributed systems 

• Specifications languages 

• Expert systems 

• Automatic program generation 

• Computer supported cooperative work 

• Large scale distributed systems 

• Human computer interaction 

• Network management 

• Information access and presentation 

• Computer networking 

• Computer communications protocols 

• High speed digital systems and VLSI 

• Large system architecture 

These positions provide excellent opportunities 
for creative individual projects, as well as col¬ 
laborative group work. The interdisciplinary 
nature of the research environment provides 
excellent opportunities for professional growth. 

As a research institution, Bellcore supports and 
rewards professional visibility. Researchers are 
encouraged to define their own projects. Com¬ 
puting and communications facilities are state-of- 
the-art. Compensation and benefits are competi¬ 
tive. Women and minority candidates are 
strongly encouraged to respond. 

In addition to these regular positions, limited- 
term openings exist. Proposals from visiting 
faculty and post-doctoral fellows are welcome. To 
explore these opportunities, send a letter of 
interest and a resume to: Manager, Technical 
Employment, Bellcore, Dept. 123/0201/90, RRC 
4C139, 444 Hoes Lane, Piscataway, NJ 08854. 

An equal opportunity employer. 
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An Expert-System Shell 
Using Structured 
Knowledge 

An Object-Oriented Approach 

K.S. Leung and M.H. Wong 
Chinese University of Hong Kong 


M ost rule-based expert systems 1 
are not flexible enough to 
handle problems that mix logi¬ 
cal deductions, rule-based inferences, and 
procedure execution, but mixed problems 
are common in modern society. Manage¬ 
ment decisions, for example, are often 
based on both rules and operations-re- 
search techniques. These problems cannot 
be solved by either a conventional expert 
system or common operations-research 
techniques alone. Their solution demands 
a new system architecture that effectively 
combines rules and procedures. 

Some conventional expert systems can 
acquire consultative data only through 
interactive input; thus, they are not suit¬ 
able for problems involving large amounts 
of data. *To overcome this drawback, auto¬ 
matic feeding of data from a database 
should be considered an essential feature 
of a new system architecture. Many pres¬ 
ent-day expert systems also take an un¬ 
structured approach to knowledge repre¬ 
sentation; thus, when the size of the knowl¬ 
edge base increases significantly, the 
knowledge can become unmanageable. To 
overcome this problem, future expert-sys¬ 
tem shells will need to use structured 
knowledge-representation methods. 2 
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Two expert systems 
built with this 
prototype shell have 
demonstrated its 
power and flexibility. 
It mixes declarative 
and procedural 
knowledge, 
overcoming a major 
problem of 
conventional shells. 


This article presents a new architecture 
for an expert-system shell. Its structured 
knowledge representations enable mixing 
rules with procedures. Its built-in database 
interface not only allows automatic extrac¬ 
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tion of data from a database management 
system, it also provides a fuzzy database 
query facility. In addition, the shell’s ob¬ 
ject-oriented approach 3 to knowledge rep¬ 
resentation supports data and knowledge 
abstraction. The approach also encourages 
modular designs, which improve the effi¬ 
ciency of knowledge acquisition and man¬ 
agement. Another feature is encapsulation, 
which prevents object manipulation ex¬ 
cept by defined operations. Overall, this 
object-oriented approach improves the 
consistency, maintainability, understanda- 
bility, and modifiability of the knowledge 
base, and, because it minimizes object 
interdependency, 4 the knowledge can be 
structured. 

Our prototype expert-system shell, 
called System X-I, includes a flexible 
knowledge-acquisition module, an infer¬ 
ence engine (backward chaining), a data¬ 
base interface, fuzzy retrieval facilities, 5 
and an external methods interface. The 
flexibility and power of System X-I have 
been proven in several implementations. 
Two case studies are presented later in the 
article, but first, let’s compare representa¬ 
tion methods and take a look at the shell’s 
overall architecture and object-oriented 
approach. 
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Classical versus 
object-oriented 
knowledge 
representation 

A knowledge-representation method is 
the way a knowledge engineer models the 
facts and relationships of the domain 
knowledge. Classical methods, such as 
semantic network^, object-attribute-value 
triplets, frames, and rules, are commonly 
used in classical expert systems. Each 
method has its own advantages and disad¬ 
vantages. 

Semantic networks. A semantic net¬ 
work 6 is composed of two tuples ( N , L). N 
is a set of nodes used to represent objects 
and descriptors. An object may be a physi¬ 
cal object or a conceptual entity, while a 
descriptor provides additional information 
about the object. L is a set of links connect¬ 
ing the nodes and representing the rela¬ 
tions among them. Some commonly used 
links are is-a and has-a links. An is-a link 
represents class and instance relationships 
and usually has an inheritance feature. A 
has-a link shows that a node has a certain 
property. Semantic networks also have 
definitional links for representing declara¬ 
tive relations. 

Object-attribute-value triplets. In the 

object-attribute-value method, knowledge 
is represented by three tuples (O, A, 7). O 
is the set of objects, which may be physical 
or conceptual entities. A is the set of attrib¬ 
utes, which are general characteristics or 
properties associated with objects. Values, 
V, specify the natures of the attributes. 

The OAV method is actually a special 
form of semantic network. The relation be¬ 
tween an object and an attribute is a has-a 
link, and the relation between an attribute 
and a value is an is-a link. The objects, 
attributes, and values of OAV are equiva¬ 
lent to the nodes in semantic networks. 
Knowledge can be divided into dynamic 
and static portions. The triplet values are 
the dynamic portion. These values may 
change, but the static portion (usually facts 
and rules) remains unchahged for different 
consultations. 

OAV is more structured than a semantic 
network. However, when the number of 
objects increases, an OAV system be¬ 
comes difficult to manage. 

Frames. A frame is used to describe an 
object. 7 It is composed of slots storing 


information associated with the object. 
The function of the slots is similar to that of 
the attributes in OAV. However, frames 
differ from OAV in that the slots may 
contain default values, pointers to other 
frames, sets of rules, or procedures. Frames 
may also be linked to allow for inheritance. 

Ultimately, frames and OAV can be 
considered special cases, or subsets, of 
semantic networks. The representational 
power of the three systems is the same. The 
difference lies in the structure and concept 
of their knowledge organizations. 

Rules. A rule has two parts. The first 
part is a premise of conditions connected 
by logical-AND or logical-OR relation¬ 
ships. The second part is a conclusion. 
When the premise of a rule is true, the 
conclusion of the rule will become true. In 
some systems, rules may be implemented 
by semantic network or OAV, as in My- 
cin, 8 the medical diagnostic system devel¬ 
oped at Stanford University. Alternatively, 
rules may be represented by frames, as in 
IntelliCorp’s Knowledge Engineering En¬ 
vironment. 9 

Evaluation and comparison. The ma¬ 
jor advantage of semantic networks is 
flexibility, since new nodes and links can 
be defined as required without restriction. 
This flexibility also exists in object-ori¬ 
ented knowledge representations where, 
by storing the names of other objects as the 
attributes of an instance object, relations 
between instance objects can be estab¬ 
lished dynamically. These relationships 
have the same power as links in semantic 
networks; in fact, this object-oriented 
construct can be viewed as a dynamic 
semantic network. The is-a links of seman¬ 
tic networks can be implemented in object- 
oriented representations by relationships 
between classes and subclasses or between 
classes and instances. Has-a links can be 
implemented by the relationships between 
classes and attributes. Therefore, object- 
oriented knowledge representation has the 
same power as a semantic network but is 
much more structured. 

A common disadvantage in semantic 
networks, rules, and OAV representations 
is that they are not structured enough. A 
significant increase in the number of ob¬ 
jects or rules makes the system difficult to 
manage. This is because the knowledge 
cannot be modularized and interactions 
among rules and objects become too com¬ 
plex. When the value of an object or an 
attribute is modified, it is difficult to pin¬ 
point the effects On the whole system. 


Therefore, such knowledge representa¬ 
tions are difficult to develop and maintain, 
especially for a large knowledge base. The 
encapsulation property and structuredness 
of object-oriented knowledge representa¬ 
tions give them a distinct edge over these 
three representations. 

Frames are more structured than seman¬ 
tic networks, rules, and OAV representa¬ 
tions, since related attributes and rules can 
be grouped into frames hierarchically. 
However, modularity of knowledge repre¬ 
sented in frames cannot be clearly defined, 
and frame representation lacks flexibility. 
In a frame system, relationships between 
frames may be member or subclass links 
and thus are not unique. Moreover, in some 
systems, a rule is represented by a frame 
linked to another frame with a special rela¬ 
tionship. These factors greatly reduce the 
structure in a frame system. In object- 
oriented knowledge representation, which 
is quite similar to frames, knowledge can 
be arranged in a hierarchical form using 
classes. However, a subclass link is the 
only possible relationship between two 
classes, an is-a link is the only possible 
relationship between a class and an in¬ 
stance object, and rules are defined as 
methods in classes — clear-cut distinc¬ 
tions that reduce ambiguity and improve 
understandability. 

System X-I 
architecture 

Our expert-system shell, System X-I, 
has four functional components: an infer¬ 
ence engine, an end-user interface, a 
knowledge-acquisition module, and an 
environment for domain knowledge. Sys¬ 
tem X-I adopts an object-oriented ap¬ 
proach for knowledge representations and 
inferences, a relatively new approach in 
expert-system shells. The knowledge rep¬ 
resentations in System X-I include both 
declarative and procedural forms. External 
routines written in other languages can 
also be invoked as procedural knowledge. 
Figure 1 shows the system’s overall archi¬ 
tecture. 

The expert-system shell contains many 
objects. All external interfaces and infer¬ 
ence and control mechanisms are imple¬ 
mented by system methods in system ob¬ 
jects. The inference engine is used to sup¬ 
port the system methods for rule inference. 
All system objects are grouped in the sys¬ 
tem class “root.” Knowledge engineers can 
use this class without any declaration. 
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Figure 1. Architecture of System X-I. 


A knowledge base of an expert system 
built from System X-I is also defined by a 
collection of classes, objects, and meth¬ 
ods. If a user-defined class is declared a 
child of the root class, it can inherit all the 
capabilities of the system methods. Thus, 
each user-defined object may be treated as 
an independent entity that inherits infer¬ 
ence capabilities from the system class 

End-users can communicate with any 
object defined by the system or by knowl¬ 
edge engineers through the user interface. 
The user interface translates user input into 
messages for invoking appropriate objects 
in the system. Messages sent to the user 
interface are decoded, and the resulting 
information is output to the screen. The 
knowledge-acquisition module captures 
the domain knowledge supplied by knowl¬ 
edge engineers, transforms it into internal 
format, and stores it in a knowledge base. 

To meet the needs of different users. 


System X-I supports two modes of knowl¬ 
edge input. Knowledge engineers familiar 
with the system and with knowledge repre¬ 
sentation can input knowledge quickly 
through conventional editors. The second 
mode, for knowledge engineers or domain 
experts who do not have a clear concept of 
the knowledge representation method, 
supports input through interrogation. 

In interrogation mode, the knowledge 
engineer selects an option from a menu 
that includes inserting classes, inserting 
instance objects, modifying classes, and 
modifying objects. For the option of creat¬ 
ing a class, the knowledge engineer must 
input some compulsory information, such 
as the name and parent of the class. An 
instance object can be created in a similar 
manner. An option for inputting optional 
information, such as class and instance 
variables and attributes, can then be se¬ 
lected. Rules are input as an optional type 
of attribute. To modify a class or an in¬ 


stance object, the knowledge engineer 
chooses the appropriate class or instance 
object from a menu. Then, a series of ques¬ 
tions or menus are used to identify and 
modify the piece of knowledge. 

Objects 

System X-I represents knowledge by a 
collection of objects. An object is an inde¬ 
pendent entity represented by some data 
and a set of operations (methods and capa¬ 
bilities). 10 Therefore, an object can be used 
to represent a variety of knowledge. 
Knowledge (X) can be formally repre¬ 
sented by three tuples, K = (C, /, A), where 
C is a set of classes and / is a set of 
instances represented by class and instance 
objects, respectively. A is a set of attributes 
possessed by the classes and instances. 
The behaviors of C, /, and A are restricted 
by the law predefined in the shell. The law 
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includes rules for inheritance, message 
passing, and encapsulation. 

Classes. A class is a description of a 
group of similar instance objects. 10 It is a 
mold that determines the behavior of its 
instances. Each class has a unique name 
and a set of attributes that define the prop¬ 
erties of the class. A class may, be a sub¬ 
class of another class and may inherit prop¬ 
erties from its parent class (see “Inheri¬ 
tance” subsection for details). 

Five sets of attributes may exist in a 
class object: 

(1) Name — the name of the class; used 
to reference a class in the system. 

(2) Superclass — the name of the par¬ 
ent of the class. 

(3) Class_variables — a set of variables 
shared among all instances of the class, 
that is, global variables accessible by all 
instances of the class. Get and Store opera¬ 
tions may be performed on them. 

(4) Instance variables — the set of vari¬ 
ables possessed by each instance of the 
class. Variables may be classified into data 
and database data. Each instance may have 
different values for these variables. 

(5) Class attributes — the set of meth¬ 
ods, external methods, and rules shared by 
all instances of the class. 

Instance objects. Instance objects are 
members of classes. Their properties are 
defined by their parent classes. Each in¬ 
stance object consists of three sets of at¬ 
tributes: 

(1) Name — the name of the object, 
which is unique in the system. It is used to 
identify the object. 

(2) Class — the class that contains the 
object. 

(3) Instance attributes — attributes be¬ 
longing to the instance object. Some op¬ 
erations may be performed on these attrib¬ 
utes. The behavior of the object is deter¬ 
mined by the values of these attributes. 

In general, an instance object i is defined 
by its class and the values of its attributes: 
i e /, where / is the set of instances in the 
system; V i e /, attribute x with any value 
v is valid for i, if val(x) = v and x are defined 
in class(i), where class(i) is a function that 
returns the name of the class of instance i 
and val(x) is a function that returns the 
value for attribute x. 

Attributes. The property of an attribute 
is determined by its type and value. The 


type of an attribute is defined by its class, 
while the value may be defined in its class 
or its instance object. In System X-I, attri¬ 
butes may be classified into three types: 

(1) Data — Attributes of this type are 
used to store simple data types such as 
integer, boolean, real, and string. Get and 
Store operations may be applied to these 
attributes. 

(2) Database data—An attribute of this 
type corresponds to one value of a field in 
a relational database of VAX Rdb. To 
define this type of attribute, the knowledge 
engineer must specify the relation name, 
field name, field type, and the key field 
defined in the database. The name of the 
attribute may be different from that of the 
field defined in the database. 

When a method is invoked to get the 
value of an attribute belonging to this type, 
the value of the data will be drawn auto¬ 
matically from the database through a da¬ 
tabase interface. 5 Besides drawing data, 
the interface provides system methods to 
draw information with relational opera¬ 
tions and to handle fuzzy queries, such as 
“select a senior man who is at least about 5 
feet 8 inches tall.” 

(3) Methods — This type of attribute is 
not for storing data but for defining capa¬ 
bilities. (See section titled “Methods” for 
details.) 

Inheritance. Properties of a class can be 
inherited from its parent’s class. This fea¬ 
ture permits factoring knowledge into a 
class hierarchy. Thus, it encourages modu¬ 
lar design of knowledge. The system 
adopts the inheritance rules, which are 
similar to those in Smalltalk, 10 as follows: 

(1) If class A inherits from class B, then 
the objects of class A support all operations 
supported by objects of class B. 

(2) If class A inherits from class B, then 
class A’s attributes are a superset of class 
B’ s attributes. 

Therefore, V c e C (the set of all classes), 
attribute x is valid for c if either x e 
class_attributes (c) or x e class_attributes 
(superclasses of c), where class_attributes 
(c) = the set of attributes of c. 

Methods 

Methods are a kind of attribute belong¬ 
ing to objects. They are used to represent 
capabilities, not to store data, and are de¬ 
fined in classes. Methods cannot be modi¬ 


fied during consultation. In System X-I, 
methods are further classified into three 
types: rules, internal methods, and external 
methods. 

Rules. In System X-I, rules are methods 
belonging to objects. They are used to find 
the values of the variable attributes. The 
corresponding rules are triggered by the 
system method Find-Val if the value of a 
variable attribute is undefined in its in¬ 
stance object or database. If the condition 
of a rule is satisfied, the conclusion will 
determine the value of the corresponding 
attribute. 

The format of a rule can be expressed as 
follows: 

Rule :== if Condition then Conclusion 
The form of Conclusion is 

Conclusion :== <attributes> is <value> 

The <value> may be a message or a 
datum of a primitive type, such as integer, 
real, string, or list. If <value> is a message, 
the method specified in the message will 
be invoked, and the result will be assigned 
to the attribute. Such a design allows a rule 
to trigger a method, thus achieving a free 
intermixing of rules and procedural knowl¬ 
edge. In addition, rules can be chained 
across objects within a class or an encapsu¬ 
lated module. If <value> is a datum, the 
value will be directly assigned to the attri¬ 
bute. 

The structure of Condition may be ex¬ 
pressed in extended Backus-Naur form as 
follows: 

Condition :== 

(AND Condition Condition*) I 
(OR Condition Condition*) I 
(Operator <attribute> <value> I 
(Unknown <attribute>) 

Operator :== 

>|<| = |>=|<= 

The value of a condition is either true or 
false. A condition may be composed of a 
number of conditions connected by logi- 
cal-ANDs or logical-ORs. Therefore, a 
condition can be defined recursively as 
shown above. The basic terms of a condi¬ 
tion are ( Operator <attributes> <value>) 
and (Unknown <attributes>). In addition, 
fuzzy concepts can be handled by rules, as 
reported in our earlier article on System Z- 
II. 11 

Internal methods. Internal methods are 
used to define knowledge in a procedural 
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Figure 2. Four possible actions by the message manager: (a) direct delivery, (b) 
block, (c) reroute, and (d) broadcast. 


form. The format of an internal method is 

(<attribute> method (lambda <argu- 
ment list> <method body>)) 

The <attribute> is the name of the 
method. The <argument list> is a list of the 
parameters needed by the method. The 
cmethod body> is a series of statements 
that are method steps. The syntax of the 
procedure body conforms to Common 
Lisp. Since messages can be sent by a 
method, a method can trigger another 
method or rules. 

External methods. External methods 
are system-supplied or user-defined proce¬ 
dures written in any computer language. 
They can be viewed as tools used by the 
objects. For example, they may be routines 
for the Simplex method, linear program¬ 
ming, integer programming, and so forth. 
Since the expert-system shell is developed 
on VAX computers using a VMS operating 
system, these procedures must conform to 
VAX procedure-calling and condition¬ 


handling standards; otherwise, they cannot 
be linked with the expert-system shell. A 
knowledge engineer only has to define an 
interface for a procedure. Once the inter¬ 
faces are defined, external methods can be 
used as if they were internal methods. The 
format of the interfaces is defined in ex¬ 
tended Backus-Naur form as follows: 

External method :== 

(<attribute> extemal_method 
(Tile <filename> 

[:entry-point <procedure name>] 

[: result cresult type>]) 

Argument* 

Argument :== 

(<argument> 

[:access Access method] 
:lisp-type <Ltype> 

[:vax-type <Vtype>]) 

Access method :== 

:in I :out 

The <attribute> is the external method’s 
name for internal identification. The <file- 
name> is the name of the file in which the 
external procedure is stored. The proce¬ 


dure name> is the name of the procedure 
and is optional. If it is neglected, the proce¬ 
dure name is assumed to be the same as the 
method name (<attribute>). The <result 
type> is the data type of the value returned 
from the procedure. If no value is to be 
returned, this field may be omitted. 
<Ltype> and <Vtype> are the types of the 
arguments interpreted by Lisp and the 
VAX/VMS system, respectively. 

Controls and message 
passing 

System controls can be classified as 
intra-object and inter-object controls. In¬ 
tra-object control is regarded as object self¬ 
coordination governed by the object’s 
capabilities (methods). In other words, 
intra-object control depends on the domain 
knowledge input by a knowledge engineer, 
and it determines the system’s microbe¬ 
havior. Inter-object control, on the other 
hand, coordinates interactions among ob¬ 
jects through inter-object communication. 
Message passing is the only means of 
communication between objects. The 
system’s macrobehavior is determined by 
the message-passing mechanism. Since 
message passing is the only way to activate 
an object, it enhances knowledge modular¬ 
ity and encapsulation. 

Message format. Messages activate the 
execution of methods in objects. A mes¬ 
sage consists of four components as fol¬ 
lows: 

(1) Sender — the name of the object 
sending the message. In System X-I, the 
sender need not be specified explicitly in 
the message. 

(2) Receiver — an item specifying the 
objects to which the message is sent. The 
item usually contains the name of an object 
(receiver). However, sometimes the name 
of the receiver is not known or cannot be 
specified directly, and, of course, mes¬ 
sages are sometimes broadcast to multiple 
receivers. System X-I has facilities to 
handle such cases. First, the name of a 
receiver may be specified indirectly by 
storing it in an attribute of the sending 
object. Second, a message may be sent to 
the sender itself by leaving the receiver 
field as an empty list. Third, a message 
may be sent to a list of receivers. Finally, a 
message may be sent (broadcast) to each 
instance of a class. 

(3) Selector — an item specifying 
which method the message is to invoke. 
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Usually it is the name of the method. 

(4) Arguments — parameters to be 
passed to the method. 

Message management. After creation 
by an object and before transmission to the 
receiver, a message is sent to the message 
manager for examination. If the message is 
valid and requires no special handling, the 
message manager redirects it to the re¬ 
ceiver. In other words, all exchanges are 
subject to system law, 12 but the process is, 
of course, transparent to users. 

In general, the message manager has 
four possible options for each message. 
First, the original message can be deliv¬ 
ered directly to the receiver specified by 
the sender. Second, the content and re¬ 
ceiver of the message can be modified. 
Modification of the receiver reroutes the 
message to another object. For example, 
when the debug option of the system is set, 
a message originally sent to, say, object A 
may be rerouted to object A2, which con¬ 
tains methods to dump some system infor¬ 
mation. Third, the message can be blocked 
and not delivered to any object. This action 
may be taken because the message is inva¬ 
lid (the receiver does not exist or the re¬ 
quired method cannot be found) or because 
the sender does not have sufficient privi¬ 
lege to invoke a particular method in the 
receiver. Finally, the message can be 
broadcast to all instances of a class. These 
four situations are shown in Figure 2a-d. 

Encapsulation and modularity. Al¬ 
though classification hierarchies in frame 
systems seem very structured, interactions 
may still exist among instance objects (leaf 
nodes). Hence, frame systems cannot 
achieve the modularity of System X-I’s 
object-oriented approach, which promotes 
encapsulation and modularity. 

Encapsulation is a technique that re¬ 
duces interdependence among different 
modules by defining strict external inter¬ 
faces for each module. 4 A module of 
knowledge is encapsulated if access by 
other modules is restricted to predefined 
interfaces. Therefore, encapsulation is tied 
to the message management mechanisms. 
As stated above, messages can be blocked 
if the sender’s privilege is insufficient to 
invoke certain receiver methods. This 
mechanism ensures encapsulation by pre¬ 
venting some primitive methods, such as 
Get and Store, from being invoked by other 
objects. An instance object’s attributes are 
accessible only to the object itself. There¬ 
fore, when the object is rewritten or its 
attributes renamed, the effects on other 
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Figure 3. Encapsulation of a knowledge module containing several objects. Only 
interface objects can exchange messages with external objects. 


objects are minimal, and encapsulation is 
achieved. 

The effects of encapsulation are closely 
related to modularity. With encapsulation, 
the contents of objects are accessible only 
via specified methods. For modularity, 
knowledge is separated into different 
modules. Since modules can interact only 
through predefined interfaces, they can be 
tested and modified separately. Knowl¬ 
edge organized in that form is quite struc¬ 
tured and is more easily managed and 
understood. 

A module of knowledge can be an object 
or a group of objects. If a module is an 
instance object, the message management 
mechanism has already guaranteed access 
only through predefined methods. To en¬ 
capsulate a module composed of a group of 
objects, the module must be arranged so 
that no object in the module, except those 
responsible for interface, will exchange 
messages with objects outside the module. 
Figure 3 illustrates this group encapsula¬ 
tion, a unique feature of System X-I. 

Inference tracing by 
time stamps 

In System X-I consultations, rule and 
frame deductions and procedure execu¬ 
tions can be freely mixed. For tracing and 
explanatory purposes, events are tracked 
using a time-stamp approach. Each mes¬ 
sage generated in the system is assigned a 
unique time stamp based on system time. 
In fact, system time is a counter of the 
number of messages received by the mes¬ 


sage manager. When the message result is 
returned to the sender, the return time is 
also marked. A unique time stamp, based 
on arrival and return times, is created and 
sent to the sender along with the value and 
certainty of the result. Therefore, each 
returned value stored in an instance vari¬ 
able has a certainty factor and a time stamp 
associated with it. 

For example, if the arrival time is 5 and 
the return time is 10, a time stamp “S-5-10” 
will be created. As it creates the time 
stamp, the message manager also creates a 
record of all information about the mes¬ 
sage. This record can be retrieved with the 
time stamp as the key. The record includes 
the time stamp, receiver, selector, argu¬ 
ments, result, and an information list ex¬ 
plaining how the result was drawn. It may 
also include the time stamps of the 
subgoals. Thus, an inference process can 
be traced. 

In short, a time stamp has two functions: 
tracing the order of message activation and 
tracing the inference process. 

(1) The activation order of messages 
can be traced by their time stamps. For 
example, if two messages have time stamps 
S-a-b and S-c-d and c and d have values 
between those of a and b, it can be deduced 
that message S-a-b directly or indirectly 
caused the generation of message S-c-d. In 
other words, the goal of finding the result 
of the message S-c-d is a subgoal of finding 
the result of message S-a-b. 

(2) With time stamps, details of corre¬ 
sponding messages can be found. Thus, the 
process by which the system determined a 
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particular result can be traced and an ex¬ 
planation generated. 

A sequential system is assumed for the 
above approach. Parallel operations using 
message passing require a more sophisti¬ 
cated time-stamping technique. 

Classification of 
problems 

Rules, procedures, and databases are 
frequently used independently to handle 
various classic computing and artificial 
intelligence problems, for instance, rules 
for rule-based expert systems, procedures 
for operations research problems, and da¬ 
tabases for management information sys¬ 
tems. However, in the X-I expert-system 
shell, all three techniques are represented 
as attributes of objects and can be inter¬ 
mixed in any proportion to model and solve 
complex problems. Rules and procedures 
usually drive and control the problem¬ 
solving process, while databases play the 
supportive role of automatic data manage¬ 
ment. The top-level control of an expert 
system built using System X-I is driven by 
either rules (goal directed) or procedures, 
although they can be freely mixed at lower 
levels. With System X-I, a knowledge 
engineer can use either, modeling the prob¬ 
lem according to his or her own style of 
working. 

Goal-directed problems. This class of 
problems uses rules for top-level control of 
the expert system. In System X-I, these 
systems are similar to conventional goal- 
directed (rule-based) systems in which the 
goal can be preset as a system goal or set 
according to user queries during consulta¬ 
tion. The system method “Find-val” is trig¬ 
gered when a message is sent to an instance 
object to find the value of an appropriate 
attribute corresponding to a query. The 
values of attributes may be obtained from 
objects or a database or through rule infer¬ 
ences. In a rule inference process, mes¬ 
sages may be generated and sent to other 
objects for finding intermediate values to 
support the inference. 

Procedural-driven problems. This 
class of problems uses procedures for top- 
level control. However, such an expert 
system built using System X-I can freely 
use heuristics, databases, and other proce¬ 
dures at lower levels to support the prob¬ 
lem-solving process. 


Case studies 

Different problems require different 
mixes of techniques and knowledge repre¬ 
sentations. Among the existing expert- 
system shells, few possess all the features 
required to solve all types of problems 
effectively. In this section, we demonstrate 
the flexibility and power of System X-I in 
two case studies of expert systems belong¬ 
ing to different classes. In the first system, 
the top-level control is procedure-driven; 
in the second, it is goal-directed. 

Case I: Distribution of courses to 
teachers. In our first case study, the prob¬ 
lem is to assign computer courses to teach¬ 
ers. The information on each teacher is 
stored in a database. Each teacher’s ability 
is measured in six dimensions: hardware, 
software, languages, business, theoretical, 
and numerical. Each course has a require¬ 
ment-, a difficulty index, and a time slot. 
The objective is to distribute these courses 
to suitable teachers such that no teacher is 
overloaded and no two courses with the 
same time are assigned to a teacher. 

A procedure is used for the highest level 
of control. To solve the problem, it is 
modeled by three classes of objects: 
courses, staff, and main (main object for 
top-level control). 

Class “courses." Each instance object 
of class “courses” represents a course and 
possesses the following data and capabili¬ 
ties (methods). 

Data: 

(1) Name — the name of the instance 
object. 

(2) Class — the class to which the ob¬ 
ject belongs. In this case, it will be courses. 

(3) Difficulty index — a scalar quantity 
indicating course difficulty and workload. 

(4) Time — the time for the course. 

(5) Requirements — the required back¬ 
ground of the assigned teacher. The re¬ 
quirements can be given in a restricted 
natural-language form of a fuzzy query 
language. 5 

(6) Id — the identity number of the 
teacher to whom the course is currently 
assigned. 

(7) Suitability — the degree of mem¬ 
bership," a value between 0 and 1 reflect¬ 
ing the assigned teacher’s ability in teach¬ 
ing the subject. 

Methods: 

(1) Select-teachter — a procedure used 
to select a list of teachers who satisfy the 


requirements, specified as the data of the 
course object in the fuzzy query language 
supported by the database interface. 5 It 
will invoke the “assign” method to select a 
teacher. 

(2) Assign — a procedure to select a 
teacher from the list obtained by the above 
method. A message will then be sent to the 
teacher object to request him or her to teach 
the course. If the teacher object refuses the 
course, another teacher will be selected. 

(3) Exchange — method to check 
whether the suitability of the assigned 
teacher is below a certain value. After the 
initial assignments, the main object will 
broadcast a message to all course objects to 
invoke the exchange method. Each course 
object will be checked by the method, 
which uses rules to determine a teacher’s 
suitability for a course. For example, if the 
suitability is less than 0.5, an exchange 
will be initiated. 

(4) Accept-exchange — a method that 
uses rules to determine whether an ex¬ 
change of courses between two teachers is 
acceptable. This method is invoked by the 
above exchange method. 

(5) List-assign — a procedure to print 
the identity number of a teacher assigned 
to a course, together with his or her suita¬ 
bility for teaching the course. 

Class “staff." Each instance object of 
class “staff’ represents a teacher. These 
teacher objects possess four data (besides a 
name and class slots) and one method as 
follows. 

Data: 

(1) Limit — the maximum workload 
that can be assigned to the teacher. 

(2) Workload — the current workload 
assigned to the teacher. 

(3) Subject-list — a list of courses as¬ 
signed to the teacher. 

(4) Time-list — a list of times of the 
courses assigned to the teacher. 

Method: 

(1) Allocate — a method invoked by the 
assign method of a course object. The 
teacher object will accept the course allo¬ 
cation if there is no conflict in the teacher’s 
timetable and the teacher is not overloaded. 

Class “main." This class has only one 
instance object, which is the main object 
responsible for the top-level control of this 
course-allocation expert system. This top- 
level control object contains three steps in 
procedural form. Step one broadcasts a 
message to all courses objects invoking 
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Case I results 

In this demonstration case, 10 courses are to be assigned to five teachers. 

A typical course object is shown as 

Name: CSC282 

Class: Courses (meaning object CSC282 belongs to class “courses”) 

Difficulty: 90 (an index given out of 100) 

Time: Ml (Monday, first period) 

Requirements: The teacher should have a strong background in both soft¬ 
ware and numerical analysis. 

The requirement is expressed in a fuzzy query condition, which is used by the 
database interface to select suitable teachers. 5 

Each teacher is modeled by an object with attributes name, class, current 
workload, and upper limit of workload. Three teacher objects belong to the class 
“staff” and two belong to “senior-staff,” a sub-class of staff. The initial workloads 
for all teachers are zero. The workload upper limits are 250 for staff and 100 for 
senior-staff. 

Five teacher objects with initial data are given as follows: 

(staffl (class staff)(workload 0)(limit 250)) 

(staff2 (class staff)(workload 0)(limit 250)) 

(staff3 (class staff)(workload 0)(limit 250)) 

(staff4 (class senior-staff)(workload 0)(limit 100)) 

(staff5 (class senior-staff)(workload 0)(limit 100)) 

The database contains the name, identity number (Id), and abilities of each 
teacher. The ability of a teacher in each of the six areas, namely, hardware 
(Hard), software (Soft), language (Lang), business (Bus), theoretical (Theo), 
and numerical (Num), is represented by a scalar quantity ranging from 0 to 10 
as follows: 

Name Id Hard Soft Lang Bus Theo Num 

Peter 1 7 9 9 6 9 8 

David 2 9 9 8 9 7 6 

John 3 8 7 6 8 8 5 

Mary 4 7 8 8 9 9 6 

Betty 5 8 7 6 8 9 6 

The expert system gave the following results after initial allocations and exe¬ 
cution of the method “exchange.” 

Teacher Id Courses Workloads 

1 CSC150E, CSC150D, CSC282 228 

2 CSC170, CSC150C, CSC150B 212 

3 CSC212, CSC142 185 

4 CSC150A 80 

5 CSC414 75 


them to find teachers for themselves. Step 
two broadcasts a message to all courses 
objects asking them to exchange teachers 
if theirs are not suitable. Step three broad¬ 
casts a message to all courses objects re¬ 
questing a printout of the teachers as¬ 
signed. 

This expert system illustrates a natural 
problem-solving methodology modeled by 
classes, objects, methods, and data. The 
relations between the courses and teachers 
are not explicitly declared in classes, but 
they are implicitly linked by methods and 
message passing. Such links are active, 
dynamic, and more flexible than the links 
in semantic networks or frames. 

Since this is an NP-hard problem, an 
optimal solution is very time consuming. 
This expert system solves the problem in 
much the same way a person would. Al¬ 
though the solution is not optimal, it is 
acceptable. (For the results of this case 
study, see the sidebar at right.) 

Case II: Management-decision expert 
system. System X-I can also develop an 
expert system that supports decision-mak¬ 
ing. In this case study of a goal-directed 
management problem, top-level control is 
rule-based, but the lower levels of problem 
solving involve both procedures and rules. 

The Pennwood Corporation has de¬ 
signed a new air conditioning system. The 
product will sell to contractors for $ 1,400, 
and the cost to the home buyer will be 
about $2,600. The estimated manufactur¬ 
ing cost is either $900 or $ 1,050. The exact 
cost cannot be determined because of 
pending labor negotiations in the material 
supplier’s industry. If there is a substantial 
wage increase or a strike, the cost will be 
$1,050. If the negotiations are successful 
and workers agree to a smaller wage in¬ 
crease, the cost will be $900. 

However, if Pennwood decides to manu¬ 
facture and market the product, the project 
will require a $400,000 investment, in¬ 
cluding sales promotion and facility ex¬ 
pansion. For the project to be successful, 
sales must cover this investment and allow 
for profit. Based on a preliminary analysis, 
sales are determined by two factors: eco¬ 
nomic conditions affecting new home 
construction and the competitive situation 
within the air conditioning industry. 

Because of the air conditioning system’s 
$2,600 price, Pennwood’s Marketing Di¬ 
vision sees a sales potential only for houses 
priced at or over $50,000. Preliminary 
market research indicates that buyers of 
approximately three percent of all new 


homes in this price range would install the 
air conditioning system if it were available 
for $2,600. Market research estimates 
construction of 60,000 residences in this 
price range under good economic condi¬ 
tions, but only 40,000 if conditions are 
bad. 

Another marketing factor is the pres¬ 
ence or absence of competition. If a com¬ 


petitor brings a similar model to market, it 
is expected that the firms will share the 
market equally. If not, Pennwood could 
expect to get the entire market. 

The objective is to determine whether 
the investment should be made. The expert 
system is modeled by two classes of ob¬ 
jects, “products” and “air-cond,” both of 
which possess only one instance object. 
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Case II results 

Three consultations for the management problem presented in Case II yielded the 
following results. 


Consultation 1 

What is the value of CONTRACT-PRICE in object AIR-CONDITION-SYSTEM 
input> 1,400 

What is the value of NEGOTIATION in object AIR-CONDITION-SYSTEM 
inputs- success 

What is the value of NO-OF-HOUSE-OWNER in object AIR-CONDITION-SYSTEM 
inputs 60,000 

What is the value of COMPETITOR-NO in object AIR-CONDITION-SYSTEM 
inputs 0 

What is the value of MARKET-PRICE in object AIR-CONDITION-SYSTEM 
inputs 2,600 

What is the value of FIX-COST in object AIR-CONDITION-SYSTEM 
inputs 400,000 

Conclusion: 

The investment is strongly recommended 
Demand = 3% 

Sales = 1800 units 
Profit = $500000 


Consultation 2 

What is the value of CONTRACT-PRICE in object AIR-CONDITION-SYSTEM 
inputs 1,400 

What is the value of NEGOTIATION in object AIR-CONDITION-SYSTEM 
inputs fail 

What is the value of NO-OF-HOUSE-OWNER in object AIR-CONDITION-SYSTEM 
inputs 40,000 

What is the value of COMPETITOR-NO in object AIR-CONDITION-SYSTEM 
inputs 2 

What is the value of MARKET-PRICE in object AIR-CONDITION-SYSTEM 
inputs 2,600 

What is the value of FIX-COST in object AIR-CONDITION-SYSTEM 
inputs 400,000 

Conclusion: 

Do not invest in the project 
Demand = 3% 

Sales = 400 units 
Profit = - $260,000 (loss) 


Consultation 3 

What is the value of CONTRACT-PRICE in object AIR-CONDITION-SYSTEM 
inputs 1,200 

What is the value of NEGOTIATION in object AIR-CONDITION-SYSTEM 
inputs success 

What is the value of NO-OF-HOUSE-OWNER in object AIR-CONDITION-SYSTEM 
inputs 45,000 

What is the value of COMPETITOR-NO in object AIR-CONDITION-SYSTEM 
inputs 0 

What is the value of MARKET-PRICE in object AIR-CONDITION-SYSTEM 
inputs 2,400 

What is the value of FIX-COST in object AIR-CONDITION-SYSTEM 
inputs 600,000 

Conclusion: 

It is profitable but there may be some risk 
Demand = 5% 

Sales = 22,500 units 
Profit = $75,000 


Class "products.” Class “products” rep¬ 
resents general knowledge that may be ap¬ 
plied to any company product. This class 
contains one datum and two methods. 

Datum: 

(1) Fix-cost — a datum used to store the 
fixed cost of the produce The value will be 
requested interactively during consulta- 


Methods: 

(1) Recommendation — an attribute re¬ 
lated to the conclusion drawn, based on a 
set of rules to determine profitability. This 
attribute is, in fact, the goal of the rule- 
driven expert system. The recommenda¬ 
tion will be given to the users at the end of 
the consultation. The rules are 

If profit > fix-cost 

Then investment is strongly 
approved 

If profit > 0 and profit < fix-cost 

Then investment is approved with 
warning 

If profit < 0 

Then investment is disapproved 

(2) Profit—a method used to find prod¬ 
uct profit. The formula is profit = (contract 
price - variable cost) * sales - fix-cost 

Class “air-cond." This class represents 
knowledge specified for the air condition¬ 
ing system only. Because “air-cond” is a 
subclass of “products,” it inherits all the 
knowledge of the products class. A knowl¬ 
edge engineer may input the data values to 
the instance objects before consultation. If 
the data values are undefined, the user will 
be asked to input the values during consul¬ 
tation. Class air-cond has the following 
data and methods. 

Data: 

(1) Contract price -— the price of the air 
conditioning system sold to contractors. 

(2) No-of-house-owner — the esti¬ 
mated number of new home owners in the 
coming year. 

(3) Competitor-no — the estimated 
number of competitors in the coming year. 

(4) Market price — the price of the air 
conditioning system sold to home buyers. 

Methods: 

(1) Variable-cost — determined by the 
result of the labor negotiation. Rules relate 
the variable-cost to the negotiation result. 
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The rules are 

If negotiation succeeds 

Then variable cost is 900 

If negotiation fails 

Then variable cost is 1050 

(2) Sales — determined by the number 
of buyers and number of competitors as 
follows: 

number of buyers 

Sales = --- 

number of competitors 

where number of buyers = number of house 
owners x demand. 

(3) Demand — the percentage of own¬ 
ers who will install air conditioning sys¬ 
tems. This capability is modeled by an 
external method written in Pascal. The 
required parameter is the market price of 
the air conditioning system. 

With the help of the expert system de¬ 
veloped by System X-I, the user can get an 
investment recommendation by answering 
a series of questions. The user can compare 
expected results under different circum¬ 
stances by giving different answers to the 
questions in a sequence of consultations. 
The results for several sample consulta¬ 
tions are shown in the sidebar at left. 

This problem demonstrates knowledge 
represented in an abstract form, since 
knowledge in the products class can be 
applied to other products besides air-cond. 
Moreover, it shows an external method, 
demand, implemented by an external rou¬ 
tine. This feature quickly links existing 
routines to the expert system. The routine 
for the demand model is well tested and has 
been used by Pennwood’s Marketing Divi¬ 
sion for a long time. Thus, it is not cost- 
effective to rewrite it for embedding in the 
knowledge base, as some conventional 
expert-system shells would do. 


T he special features of this expert- 
system shell can be summarized 
as follows: 

(1) Knowledge can be represented by a 
mixture of rules, procedures, is-a relations, 
and has-a relations in any proportion. 

(2) Knowledge can be represented in 
both active (method) and passive (data) 
forms. In fact, an object-oriented data¬ 
base can be easily implemented using 
System X-I. 


(3) Knowledge can be represented in a 
structured form, since the object-oriented 
approach provides modularity and encap¬ 
sulation. Related rules can be grouped in a 
class or a module that is independent of 
other classes. This enhances manageabil¬ 
ity, understandability, and maintainabil¬ 
ity. 

(4) Inheritance properties exist between 
classes and subclasses. Thus, knowledge 
can be represented in an abstract form with 
common features grouped in a superclass. 

(5) Data required during consultations 
can be supported by a database. Therefore, 
interactive inputs can be minimized. 

(6) Methods can be defined by any other 
language conforming to the VAX proce¬ 
dure-calling and condition-handling stan¬ 
dards. 

Unique features of System X-I include 
group encapsulation, fuzzy queries and 
rules, time stamp-driven explanations, and 
flexible top-level control. It is the realiza¬ 
tion of the integration of expert, proce¬ 
dural, and database systems for future 
computer applications. 

We hope our experience with System X- 
I will help bring into focus knowledge¬ 
engineering problems such as structured¬ 
ness and maintainability, which are similar 
to those of software engineering. ■ 
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The Object-Oriented 
Structured Design Notation 
for Software Design 
Representation 


Anthony I. Wasserman, Peter A. Pircher, and Robert J. Muller 
Interactive Development Environments 


T he overall architecture of a soft¬ 
ware system has long been recog¬ 
nized as important to its quality 
(or lack thereof). An architecture’s build¬ 
ing blocks include units that carry out the 
system’s functions, connections that show 
how these units transmit or share informa¬ 
tion, and connections that show how the 
various functions are activated, either se¬ 
quentially or concurrently. 

A well-structured system follows basic 
principles of software design. It should 
exhibit a logical and modular architecture 
and support information hiding. * 1 The de¬ 
signer should isolate his or her design 
decisions from each other, build systems 
out of separately specifiable units, and 
publish the units’ interfaces. 

While these design principles are gener¬ 
ally accepted, there is little agreement on 
either design methods or a notation to 
represent designs. Indeed, there is a prolif¬ 
eration of such notations rather than a 
single well-known and widely used repre¬ 
sentation as is found in other engineering 
disciplines. 2 

Our goal was to address both design 
representation and design methodology. 
We set out first to develop a notation that 
supports the key software structure con¬ 
cepts and design principles. In other words, 
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Object-oriented 
structured design 
notation can serve the 
same purpose for 
software systems as 
schematics and block 
diagrams do for 
electrical engineering. 


the notation should let designers represent 
modules, interfaces, hidden information, 
concurrency, message passing, invocation 
of operations, and overall program struc¬ 
ture in a comprehensible way. We defined 
the requirements for an architectural de¬ 
sign representation as follows: 

(1) It should support a wide variety of 

systems, including both sequential and 
concurrent models of execution. 

0018-9162/90/0300-00S0S01.00 © 1990 IEEE 


(2) It should support object-oriented 
concepts, such as abstract data types, class 
hierarchies, and inheritance. 

(3) It should offer design reusability so 
that parts of designs, along with their asso¬ 
ciated properties, can be placed in a library 
and reused in other designs. 

(4) It should offer language independ¬ 
ence at the architectural level, since de¬ 
signers may make architectural design 
decisions based on language and implem¬ 
entation issues. 

(5) It should offer method independ¬ 
ence so that the notation does not require a 
particular design approach. 

(6) It should be convenient so that it is 
not overly complex to record and compre¬ 
hend designs. 

We wanted to create a standard design 
notation that could represent every soft¬ 
ware design, independent of the design 
approach used. We assumed that the repre¬ 
sentation would be supported by auto¬ 
mated tools to create, edit, browse, and 
reuse designs,' as well as to check for con¬ 
sistency and support later stages of devel¬ 
opment. 

It is important to understand that the 
notation that represents a design is inde¬ 
pendent of the the method that derives the 
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Concepts and terminology 

Object-oriented design approaches are based on identify¬ 
ing the classes of objects in a system. Classes are described 
in terms of their behavior and structure, with each object 
modeling a real-world entity. The class and its operations are 
defined as a single unit. Each object is a member of a class, 
and the operations are defined for all members of a class. 

Object-oriented design identifies appropriate classes for a 
given system. These classes are often derived from classes 
used for previous designs, thereby supporting reuse. 

Object-oriented programming refers to programming-lan¬ 
guage support for object orientation. Object-oriented pro¬ 
gramming languages include C++, Objective-C, Eiffel, Small¬ 
talk-80, and CLOS (Common Lisp Object System). Ada pro¬ 
vides a limited capability to define classes, while languages 
such as Fortran, C, Pascal, and Cobol provide no explicit 
support for object orientation. Note, though, that there is a 
proposal before the Codasyl committee for object-oriented 
Cobol, and that some of these languages have object-ori¬ 
ented extensions, such as Borland’s Turbo Pascal 5.5. In any 
case, an object-oriented design can be implemented in all of 
these languages. 

Definitions 

Abstract data type — An abstraction similar to a class that 
describes a set of objects in terms of an encapsulated or hid¬ 
den data structure and operations on that structure. 

Class — An abstraction of a set of objects that specifies 
the common static and behavioral characteristics of the ob¬ 
jects, including the public and private nature of the state and 
behavior. 

Generic package — A parameterized Ada package (see 
"package”). 

Generic definition — The ability to parameterize a class. 

Inheritance — Single: A relationship between classes 


whereby one class acquires the structure of other classes in 
a strict hierarchy from a single parent. 

Multiple: A relationship between classes whereby one class 
acquires the structure of other classes in a lattice with mul¬ 
tiple parents. 

Instance — One object in the set of objects described by a 
class abstraction. 

Instantiation — The creation of a new instance object of a 
class or a new specific class from a generic class. 

Message — A request for an object to carry out the se¬ 
quence of actions in one of the operations of its class. 

Method — In Smalltalk, an operation that returns an object. 

Object — An element of a computer system that has a 
unique identity, state (represented by public and private 
data), and public and private operations that represent the 
behavior of the object over time. 

Operation — A class-level abstraction describing a se¬ 
quence of messages or actions that access or change the 
state of an instance of a class. 

Overloading — A simple form of polymorphism; the ability 
to attach more than one meaning to the same name in the 
same scope as differentiated by type or some other class 
characteristic. 

Package — An Ada construct that declares a set of data 
and program units in a single program unit and that can be 
used to create an abstract data type. 

Polymorphism — The ability of an entity to refer at run¬ 
time to instances of various classes. Hence, the actual opera¬ 
tion performed on receipt of a message depends on the class 
of the instance. 


design. While the notation might allow 
both “good” and “bad” designs to be repre¬ 
sented, a design method suggests a strat¬ 
egy for deriving the best possible design, 
possibly including metrics that evaluate 
design quality. Of course, a standard de¬ 
sign notation can admit numerous design 
methods. We gave particular attention to 
object-oriented design approaches, though 
not to the exclusion of other approaches. 

Architectural design 
approaches 

Approaches to software system design 
fall predominantly into three categories: 


object-oriented design, functional decom¬ 
position, and data structure design. 

Object-oriented design. Booch 3 de¬ 
fines an object as a model of a real-world 
entity that combines both data and opera¬ 
tions on that data. Each object is a member 
of a class. Operations (also called proce¬ 
dures, methods, messages, or services) can 
be defined on both classes and objects. 

Object-oriented design uses classes or 
objects as the building blocks of a software 
architecture. Booch’s original work on 
object-oriented design was strongly influ¬ 
enced by the characteristics of Ada pack¬ 
ages and tasks; he is now extending that 
work to support more general class rela¬ 
tionships as they exist in other object- 


oriented programming languages. 

Hierarchical object-oriented design, 4 
developed by the European Space Agency, 
is closely related to Booch’s work. HOOD 
includes a “uses hierarchy” to show how 
abstract objects use one another and also 
supports active and passive objects, where 
active objects interact directly with a con¬ 
trol flow. An important goal of HOOD is to 
map its features directly to Ada concepts 
through an object-definition skeleton as¬ 
sociated with each object. The skeleton 
strongly resembles a formal specification 
language or a‘program design language. 

Functional decomposition. Functional 
decomposition partitions the system ac¬ 
cording to its functions. Typically, the 
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Figure 1. Definition of a stack. Figure 2. Use of class definitions with visibility. 


design proceeds “from the top down” by 
successively refining functions. Struc¬ 
tured design, 5 the most widely used archi¬ 
tectural design method, is based on the 
principles of modular decomposition. 
Designs can be evaluated based on module 
strength (the extent to which a module 
performs a single function) and on module 
coupling (the ways data is shared among 
modules). 

Structured design is represented by a 
structure chart, which shows modules, 
their connections to other modules, and 
their activation. The complete notation is 
quite extensive and supports such concepts 
as lexical inclusion of one module within 
another, asynchronous activation of mod¬ 
ules, modules containing only data, and 
macros, in addition to the basic module¬ 
calling and parameter-passing informa- 


Data structure design. The data struc¬ 
ture approach derives the logical data 
structures for the application. This ap¬ 
proach has been widely followed in infor¬ 
mation systems design, where system 
development begins by creating concep¬ 
tual and logical models of all the data used 
in all the information systems that will 
share the database (enterprise modeling). 6 
Application development then involves 
writing programs that manipulate the data¬ 
base created from the logical data model¬ 
ing. 


OOSD notation 

To achieve our goal we conceived a 
design notation called object-oriented 
structured design. The basic ideas of 
OOSD come from 

• structure charts in structured design; 

• Booch’s notation for Ada packages 
and tasks, generalized to be language- 
independent; 

• class hierarchy and inheritance prin¬ 
ciples from object-oriented program¬ 
ming; and 

• Hoare’s monitors for concurrent pro¬ 
gramming. 7 

OOSD provides a standard design nota¬ 
tion by supporting concepts of both struc¬ 
tured and object-oriented design. The no¬ 
tation includes the basic symbols of struc¬ 
ture charts to illustrate modules and their 
interconnections, including calling struc¬ 
tures and parameter passing. This ap¬ 
proach builds on a notation familiar to 
most software engineers. OOSD also sup¬ 
ports object-oriented design concepts, al¬ 
lowing someone familiar with Booch’s 
method or with HOOD to use OOSD 
immediately. At the same time, a designer 
could ignore the structure chart symbology 
and exclusively use OOSD’s object-ori¬ 
ented concepts to represent a “pure” ob¬ 
ject-oriented design. In short, OOSD nota¬ 
tion is a superset of structure charts and 
Booch’s notation, and thereby accommo¬ 


dates two important design notations. 

The following examples introduce 
OOSD notation, including classes, excep¬ 
tions, visibility, inheritance, generics, 
monitors, and extensions for detailed de¬ 
sign. We use familiar examples, such as 
stacks, tables, and buffers, and emphasize 
those aspects of the notation that address 
object-oriented design concepts. Sidebars 
offer a glossary, the complete set of sym¬ 
bols, and a formal textual equivalent of the 
notation. 

Classes 

A class (or abstract data type) definition 
isolates the representational information 
about objects so that users of the class have 
access only to externally defined opera¬ 
tions. This concept is supported in numer¬ 
ous modern programming languages, in¬ 
cluding classes in Eiffel, 8 Objective-C, and 
C++, packages in Ada, and modules in 
Modula-2. 

A well-known example of a class is a 
last-in, first-out stack. In its simplest form, 
a stack has only two operations: push, 
which places an item on top of the stack, 
and pop, which removes an item from the 
stack and returns the item’s value. 

OOSD defines such a stack class with a 
rectangle and uses overlapping small 
boxes to show the push and pop operations 
(see Figure 1). Using the parameter-pass- 


52 


COMPUTER 










































Figure 3. Showing exceptions in the definition of a stack. Figure 4. Showing hidden operations. 


ing notation of structure charts, calls (indi¬ 
cated by arrows) into the push and pop 
operations show that push accepts item as 
an input data parameter and pop returns 
item as an output data parameter. Both 
operations also require an object of the 
stack class, denoted by <stack>, as an in- 
out data parameter. The placement of the 
operation boxes is not significant, so they 
can overlap the class rectangle anywhere 
around its perimeter. Followers of struc¬ 
tured design might prefer to place the 
boxes on top, while followers of Booch 
and HOOD might prefer to place the boxes 
on the left. Note that the instance data 
named “stack data” is within the class 
definition to indicate that the representa¬ 
tion information for the class is hidden 
from users of the class. The notation for 
stack data is that of a data module in struc¬ 
ture charts. 

This notation conveys more information 
about module connectivity than is found in 
HOOD, for example, where all operations 
are grouped in a single box with no way to 
show the parameters for each operation 
individually. 

After defining a class, the designer in¬ 
stantiates its objects. This step corresponds 
to a declaration in most programming lan¬ 
guages. Such declarations are given in 
connection with the use of the class, not its 
definition. A class is visible to a module (or 


another class) that is using it, so the module 
can use the class’ external properties, such 
as its operations. Visibility is denoted by a 
thick line connecting the module to the 
class. An output data parameter on the 
visibility connection indicates the declara¬ 
tion (instantiation) of one or more objects 
of the class. Figure 2 shows the module 
“save state,” which uses the stack class and 
instantiates 103 different objects of the 
class (si, s2, s3, and an array st of 100 
elements), all of which are variables in 
save state. The module notation comes 
from structure charts. 

The <stack> parameter is an object of 
the stack class and indicates that save state 
uses the associated operations on any ob¬ 
ject of the stack class. Thus, the push op¬ 
eration in Figure 2 can be applied to the 
stacks si, s2, s3, or any member of st. This 
notational convention shows the coupling 
between program units without descend¬ 
ing into detailed design to show every 
specific use of the operations. 

OOSD denotes that a module uses a 
class by a connection between the calling 
module and the operations it uses. When a 
module does not use all of a class’ opera¬ 
tions, showing only the operations used 
describes the module connections more 
explicitly and reduces potential visual 
clutter. Figure 2, for example, shows only 
the push operation, since the pop operation 


is not used. Note also that an actual 
parameter x is provided for the formal 
parameter “item.” The designer can thus 
specify module interconnections fully and 
check both the definition and use of a class 
for consistency in the number and types of 
parameters. 

Exception handling. Push and pop 
operations can lead to exceptional condi¬ 
tions. A push operation could cause an 
overflow, for example, while a pop opera¬ 
tion on an empty stack would cause an 
underflow. Changing the stack definition 
as shown in Figure 3 shows the possible 
over and under exceptions. A diamond 
indicates the visibility of these exceptions; 
exception parameters also use a diamond 
and show more specifically the exceptions 
that specific operations can raise. 

Hidden operations. All operations in a 
class need not be visible outside the class’ 
definition. OOSD notation, in which vis¬ 
ible operations overlap the class symbol, 
suggests a visible part and a hidden part. 
The operation can be placed completely 
within the class symbol to show that the 
operation is completely hidden from out¬ 
side use. Figure 4 shows an example in 
which the “is full” operation is used by 
push but is internal to the stack class defi¬ 
nition. 
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Figure 6. Definition of complex table 
from generic table. 


Inherited and generic definitions. 

Object-oriented design requires that gen¬ 
eral classes of objects can contain more- 
specific subclasses. Since classes repre¬ 
sent objects, their properties, and the op¬ 
erations on them, OOSD must allow in¬ 
heritance — a hierarchy of classes and the 
derivation of new classes from existing 
ones. A subclass inherits properties of the 
general class and can have additional dis¬ 


tinguishing properties. For example, poly¬ 
gon might be a general class with proper¬ 
ties such as number of sides and longest 
side. Rectangle would be a subclass of 
polygon, and square a subclass of rec¬ 
tangle. 

Generic definitions. Generic definitions 
are closely related to inheritance. They let 
the designer define a family of related 
classes by providing parameters for class 
definitions, such as stack size or the type of 
items to be pushed onto a stack. 

Consider, for example, the general class 
of tables. Tables have records, each with a 
given number of fields. Fields, in turn, are 
of a specific record type. In every case, 
though, the basic operations on records 
will include inserting a new record, delet¬ 
ing a specific record, and searching for a 
record with a specific value in a key field. 

Thus, this general class represents a 
class generator or macro from which a 
class can be defined. The definition of 
table includes two parameters that deter¬ 
mine the maximum table size and the rec¬ 
ord type. These generic parameters are 
used to produce a specific table class. 

Figure 5 shows the design representa¬ 
tion of the generic table. The dashed lines 
around table and the two generic parame¬ 
ters (size and rectype) show that table is 
not a class or package by itself but is used 
to generate a package. 

Figure 6 then shows the class “complex 
table” as an instance of the generic table. 


Parameters with dashed arcs transmit the 
actual values of the generic parameters, 
supplying the value “complex” for the 
rectype parameter and “100” for the size 
parameter. Objects of the class complex 
table can now be instantiated, and the class 
operations insert, delete, and search can be 
called by other program units. 

Inherited definitions. Consider a class 
with a defined set of operations. In a class 
hierarchy, a designer can define a new 
class that inherits all of these operations 
and adds or substitutes new operations 
appropriate to the subclass. 

For example, a symbol table, as used in 
a compiler, could be defined as a subclass 
of the table class described above. As such, 
it would inherit table’s insert, delete, and 
search operations along with its properties. 
This inheritance is indicated in Figure 7 by 
a dashed line between the two class defini¬ 
tions. However, symbol table’s definition 
also redefines insert and contains opera¬ 
tions specific to the new class: enter block 
and leave block. Although this example 
does not use generic classes or parameters, 
the same concept of inheritance applies to 
generic definitions. 

This example illustrates several power¬ 
ful aspects of object-oriented design. Type 
extension is available, since the newly 
defined class can contain new operations. 
Type specialization is also available, since 
existing operation names can be redefined. 
OOSD thus supports polymorphism, 
where the same operation name can define 
different operations for different classes. 

Multiple inheritance. OOSD also sup¬ 
ports multiple inheritance, so a class can be 
defined based on operations and data from 
two or more other classes. Aksit and Tripa- 
thi 9 define a set of classes using multiple 
inheritance (see Figure 8). The point class 
defines the location, move, and display 
operations. The bounded point class is 
derived from point and allows movement 
of the point within a range. Bounded point 
inherits the location and display opera¬ 
tions, redefines the move operation, and 
adds the operations min, max, setmin, and 
setmax. The history point class is also 
derived from point, inherits the move and 
display operations, and redefines the loca¬ 
tion operation to maintain a history of all 
locations for a point. Finally, the bh_point 
class is derived from both bounded point 
and history point; inherits the display 
operation from point; inherits the move, 
min, max, setmin, and setmax operations 
from bounded point; inherits two location 
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Figure 7. Defining the symbol table 
class, which inherits from table class. 


operations from point (through bounded 
point) and history point; and defines a new 
operation, bounds history. 

Designers must address ambiguous in¬ 
herited operation names when considering 
multiple inheritance. In the previous ex¬ 
ample, location and move could have been 
inherited from history point, since they are 
not redefined in bh_point. In general, a 
designer can resolve this potential ambigu¬ 
ity by fully qualifying the operation name, 
showing both the class and operation name 
for the inherited operation. 

Late binding. All the examples so far 
have assumed that a class could be defined 
with a known set of operations. Yet this is 
not always the case. Designers often need 
to provide a mechanism whereby the name 
of the operation to be performed is sup¬ 
plied at runtime. Such a mechanism is 
available in numerous programming lan¬ 
guages, including Algol 60, Lisp, and 
Smalltalk-80. Ada’s generic function fea¬ 
ture works similarly. 

When programming some object-ori¬ 
ented systems, such as Sun Microsystems’ 
SunView, designers must provide for a 
callback function, where the name of the 
function is supplied at runtime. OOSD 
places brackets around the name of the 
module or class operation to show that the 
name is supplied as a parameter (see Fig¬ 
ure 9). 



Figure 8. Multiple inheritance. 


Asynchronous 

processes 

Structured design allows an external 
interrupt or event, not just a call, to initiate 
an operation. Structure charts denote this 
asynchronous activation of a module by a 
dashed line between modules rather than 
the solid line that denotes a traditional 
calling relationship. Modern software 
architecture must model communicating 
processes that might not be in a calling 
relationship with one another, for example, 
several loosely coupled asynchronous 
processes on each of a set of networked 
processors. Structured design’s traditional 
module structure would be inadequate in 
such a case. 

Accordingly, OOSD uses monitors to 
define and use asynchronous processes. 
We chose monitors, as the foundation for 



Figure 9. Delayed binding of an opera¬ 
tion or module name. 
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Figure 10. Definition of a buffering 
monitor. 


concurrency because of their structural and 
conceptual resemblance to abstract data 
types. 

Consider concurrent reading from and 
writing to a buffer. The buffering monitor 
has an internal data structure, called buffer 
data, and is affected by two operations: 
put, which places a buffer full of data in the 
buffer data structure, and get, which emp¬ 
ties a buffer full of data. The buffer con¬ 
tents are passed to and from the buffering 
monitor. Details of concurrency manage¬ 
ment (that is, mutual exclusion on the 
buffer data structure) are hidden within the 
buffering monitor. 

Figure 10 shows this definition. The 
notation resembles that of the stack defini¬ 
tion, except that a parallelogram (Booch’s 
task symbol) represents the monitor. Note 
that we have generalized Booch’s notation 
from that of an Ada rendezvous to the more 
general model of a monitor. 

Figure 11 shows the buffering monitor 
as part of a consumer/producer model, in 
which read and write procedures invoke 
the put and get processes, which are part of 
a “manage printing” class. The lexical 
inclusion symbol (the forked solid line) 
shows that the monitor is nested inside the 
manage printing class and is thus hidden 
from other system units. Alternatively, the 
buffer monitor could be drawn inside the 
manage printing class. Note that the put 
and get processes are called by the opera¬ 
tions “produce buffer” and “consume 
buffer.” 

Real-time systems and message-passing 
environments contain other examples of 
asynchronous processes. Figure 12 shows 
the activation of the field operation of a 
monitor named “keyboard interrupt han¬ 


dler,” where the dashed line indicates that 
the activation is asynchronous. 

OOSD notation also supports generic 
monitors, which are indicated by a dashed 
parallelogram. Generic monitors are use¬ 
ful for a set of related monitors, such as 
device handlers in an operating system. 

Design methods and 
rules 

We have focused so far on a graphical 
notation for representing software archi¬ 
tecture without addressing the method by 
which a design should be derived. It is not 
our intent to prescribe a single best design 
method (although we admit to certain pref¬ 
erences in that regard). We have often 
found that good designs rely on a combina¬ 
tion of “top-down” and “bottom-up” tech¬ 
niques. 

OOSD notation is “neutral” with respect 
to the design method and only excludes 
meaningless or inconsistent designs, such 
as those with invalid duplicate use of 
names, type conflicts, and unconnected 
design units. We expect that designers will 
develop and use their own design aesthet¬ 
ics and design metrics within OOSD’s 
framework, which simply provides a valid 
design notation much like a schematic or a 
blueprint. 

OOSD supports a wide variety of design 
philosophies. Since OOSD supports struc¬ 
tured design notation, a designer could 
gradually shift from current design prac¬ 
tices to a style that introduces object-ori¬ 
ented concepts into new or modified parts 
of a system. While such a hybrid notation 
might not be aesthetically appealing, it 
supports very well such tasks as converting 
programs (and programmers) from C to 
C++. Some designers prefer to restrict their 
design notation exclusively to the object- 
oriented concepts, using only the message- 
and parameter-passing symbols from 
structure charts. Such an approach is ideal 
for experienced designers performing ob¬ 
ject-oriented design to be implemented in 
an object-oriented language. Practitioners 
of Booch ’ s method or HOOD, for example, 
can use OOSD notation with few changes 
from current practice. 

Several design methods, notably 
HOOD, recommend a seniority hierarchy 
of classes, where the operations in a class 
use operations of a subordinate class. For 
example, such a hierarchy might show 
stack class as senior to list class, where the 
operations defined pn stack would use the 


produce 

consume 

buffer 

buffer 


jbuffer 

buffer T 

/ buffering 


Figure 11. Buffering processes. 


operations defined on list. OOSD can show 
such a hierarchy, where each class defini¬ 
tion can subsequently be decomposed to 
show its methods and structure. 

The designer can then add design rules 
to evaluate the resulting designs. Struc¬ 
tured design, for example, contains some 
measures of design quality based on cohe¬ 
sion and coupling. HOOD contains a de¬ 
sign rule stating that the design must fol¬ 
low a global top-down strategy with no 
cyclic use of objects. 

Note that it is often impossible to intro- 



Figure 12. Asynchronous activation of 
the field operation. 
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duce or enforce strict design rules. For 
example, other HOOD design “rules” state 
that “objects should show a low fan-out” 
and “objects should show a high fan-in.” 
However, neither “low” nor “high” is de¬ 
fined, and “should” is a guideline, not a 
rule. 

As more design methods are established 
for OOSD, we anticipate that guidelines 
and rules will emerge. For example, there 
is a general guideline in structured design 
that the fan-out (the number of modules 
called) for a given module should not 
exceed seven. A comparable guideline for 
a class definition might be a suggested 
maximum number of operations for a 
single class (perhaps 20, not counting 
operations inherited from superclasses), in 
which case a high number might indicate 
that the class should be split into two or 
more classes in an inheritance relation¬ 
ship. While there will be valid situations 


where the guidelines do not hold, an excep¬ 
tion to the guideline typically deserves 
careful review and a rationale. 

An example 

A system to organize a technical confer¬ 
ence can illustrate class hierarchies, sen¬ 
iority hierarchies, and other OOSD con¬ 
cepts. This example is similar to the fol¬ 
lowing example from the IFIP compara¬ 
tive review of information system design 
methodologies. 10 

A conference has technical sessions, each 
of which is either a paper session or a panel 
session, and an exhibition. People can submit 
papers to a program committee, which re¬ 
views them and selects a subset for presenta¬ 
tion at conference paper sessions, assigning 
the selected papers to paper sessions. Each 
session is assigned a title, a chairperson, a 
meeting room, and a session time. People 


may attend the technical conference or just 
the exhibition, at which vendors display their 
products. 

We can use a class hierarchy to solve the 
problem, starting with the person class and 
its subclasses, conference attendee and 
exhibit attendee. Speaker is then a subclass 
of conference attendee (see Figure 13). 

There is also a seniority hierarchy of 
classes, which illustrates a visibility hier¬ 
archy. The conference class uses the tech¬ 
nical program class, which uses the paper 
session class, which in turn uses the paper 
class (see Figure 14). Each of these has its 
own defined set of operations and can also 
have hidden class or instance data. Figure 
15 shows the detailed definition of the 
paper session class. Panel session’s defini¬ 
tion can easily reuse much of paper 
session’s definition, omitting the assign 
paper operation and possibly adding an 
assign panelist operation. This would be 
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Figure 15. Definition of the paper session class. 


done by making both panel session and 
paper session subclasses of session, 
thereby omitting the assign paper and as¬ 
sign panelist operations of the paper and 
panel session subclasses, respectively. 
(The class hierarchy in Figure 13 could 
also be revised to show panelist and author 
as subclasses of speaker.) 

Each operation in each class can be re¬ 
fined through detailed design and subse¬ 
quent implementation. The class hierarchy 
diagrams are also suitable for system speci¬ 
fication, since they provide a nonprocedu¬ 
ral description of the behavior of the vari¬ 
ous system operations. This description 
could be either informal (using text) or 
rigorous (associating preconditions and 
postconditions with each operation). Simi¬ 
larly, the definition of various data items 
and message structures could be left unde¬ 
fined, or it could be defined with a formal 
grammar as in structured analysis. 

While this example is small and shows 
little detail, it does show that OOSD nota¬ 
tion encourages design partitioning and 
information hiding. 

Beyond architectural 
design 

A software system’s architectural de¬ 
sign is simply the first step in transforming 
the specification of system behavior into 
an implementation that satisfies the speci¬ 
fication. Thus, no description of an archi¬ 
tectural design notation is complete unless 
it addresses the later stages of the develop¬ 
ment process. 

During architectural design, OOSD 
notation is intended to be language-inde¬ 
pendent, although many languages do not 
support all the design concepts that OOSD 
can represent. As development proceeds 
and implementation issues become in¬ 
creasingly important, the notation must be 
interpreted in the context of a particular 
programming language. Furthermore, 
additional detail must be supplied so that a 
correct implementation can be made. 

It is helpful to think of a mapping from 
each OOSD symbol to the target program¬ 
ming language. For example, the class 
symbol in OOSD maps directly to a class in 
C++ or Eiffel. The absence of such a 
mapping suggests a mismatch between the 
application and the implementation lan¬ 
guage. For example, since Fortran does not 
directly support concurrency, it would be 
an inappropriate choice for a design that 
relies on monitors. A designer who knows 


that the system is to be implemented in 
Fortran should use only those symbols for 
which a suitable mapping exists. 

On the other hand, programming lan¬ 
guages often contain more detail than is 
present in OOSD notation. There are no 
explicit symbols in OOSD to represent 
such specialized concepts as limited pri¬ 
vate types in Ada or virtual functions in 
C++. Instead, these constructs are handled 
by adding annotations to the design. Each 
symbol can have a set of properties and 
values, where the appropriate set of prop¬ 
erties depends on the type of symbol and 
the target programming language. These 
annotations can be added throughout the 
design and implementation process. 

The decision to limit the number of 
symbols in OOSD potation and to handle 


detailed design and language dependen¬ 
cies with annotations was made explicitly 
to reduce diagram complexity and high¬ 
light the essential design components. At 
the same time, however, it can be valuable 
to augment the basic notation with addi¬ 
tional language-specific symbols as the 
detailed design is elaborated. Thus, a de¬ 
signer can use the basic symbol set for 
architectural design and then add a small 
number of additional symbols to provide a 
mapping to specific features of the target 
programming language. 

Detailed design for Ada. Ada does not 
directly support the OOSD concept of a 
class, but rather uses a package construct 
for the same purpose. An Ada package 
consists of a package specification and a 
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OOSD formal grammar 

The following extended Backus-Naur form describes a textual notation for object-oriented structured design that repre- 

sents OOSD concepts 

n textual, as opposed to graphical, form. This representation can also represent OOSD designs 

in nongraphical form (a program design language). 

The keywords of the language appear in boldface and are language primitives. Various literal punctuation marks ap- 

pear in double quotes The only other primitive is the identifier, which is a string of any length that contains no blank 

characters. The notation uses the plus sign (+) to indicate token separation; any white space character is treated as 

such a separator. The vertical bar (|) represents a choice between alternatives. Brackets ([ ]) indicate optionality. 

system 

= system + system_name + “(” + unitjist + “)" 

system name 

= identifier 

unitjist 

= unit | unit list unit 

unit 

= simple_unit | generic_unit | library_unit 

simple_unit 

= class | module | monitor 

class 

= class + class_name + class_parts + named end 

class name 

= unit name 

class_parts 

= [ superclass_part ] + [ visibility_part ] + [ public part ] + [ exception part ] + [ private part ] 

superclassjoart 

= inherits from + “(" + class list + “)” 

class list 

= class name | class list + + class name 

visibility_part 

= uses + + uses list + “)" 

uses list 

= class list 

public_part 

= exports + “(” + export_unitJist + “)” 

export_unit_list 

= unit | export unit list + + unit 

exception_part 

= raises + “(” + exceptionjist + “)” 

exceptionjist 

= exception name | exception list + + exception name 

exception_name 

= identifier 

private_part 

= unitjist 

module 

= data_object | operation 

data_object 

= data object + data_object_name + + type + named_end 

data_object_name 

= unit_name 

type 

= class_name | dynamic 

operation 

= operation + operation_name + interface_parts + body_part + named_end 

operation_name 

= unit_name 

interface_parts 

= formal_param_part + exception_part + visibility_part 

body_part 

= + [ statements ] + “}” 

statements 

= statementjist 

statementjist 

= statement | statementjist + + statement 

statement 

= sequential_call | asynchronous_call | iterative_call | conditional_call 

sequential_call 

= calls + operation_name + actual_param_part 

actual_param_part 

». “(” + [ actual_params ] + “)” 

actual_params 

= actual_paramjist 

actual_paramjist 

= actuaLparam | actual_param_list + + actual_param 

actual_param 

= param_name + “=>” + data_module_name 

asynchronous_call 

= asynch + sequential_call 

iterative_call 

= loop + body_part 

conditional_call 

= cond + body_part 

monitor 

= monitor + monitor_name + class_parts + named_end 

monitor_name 

= unit_name 

generic_unit 

= generic + formal_param_part + simple_unit 

formal_param_part 

= “(” + [ formal_params ] + “)" 

formal_params 

= formal_paramJist 

formal_paramJist 

= formal_param | formal_paramJist + + formal_param 

formal_param 

param_name + + type + mode 

param_name 

identifier 

mode 

in | out | in_out | controljn | control_out | genericjn | generic out | genericJn_out | 


exception 

library_unit 

= library + simple_unit 

named_end 

= end + unit_name 

unit_name 

= identifier | unit_name + + identifier 
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package body, where the external interface 
to the package is defined in the specifica¬ 
tion. The nearest thing Ada has to a class is 
a limited private type exported from a 
package, where the package specification 
also includes the names of all the opera¬ 
tions that can be performed on objects of 
that type. 

To define a stack package in Ada, we 
modify the original OOSD design, adding 
a rounded rectangle symbol for an ex¬ 
ported type (see Figure 16). An associated 
annotation for the stack type would define 
it to have the property “limited private.” 

Similarly, Ada has a very detailed and 
powerful set of features for tasking, based 
on the notion of a rendezvous. OOSD’s 
high-level monitor symbol needs further 
elaboration during detailed design and 
programming to support the rendezvous 
and its associated features. While this in¬ 
formation can be captured with annota¬ 
tions and Ada code, we have also found it 
useful during detailed design to add the 
guard symbol and the sequencing notation 
from Buhr’s Ada structure graphs." Figure 
17 shows the detailed design of Figure 10’s 
buffering example using these additional 
symbols. 

The distinction between the architec¬ 
tural and detailed designs is useful for 
reusability. Many design components can 
(and should) be specified in a language- 
independent way prior to implementation. 
If this is done, designers can build catalogs 
of reuse libraries to apply to a variety of 
systems implemented in different lan¬ 
guages. Furthermore, the detailed design 


or implementation of an architectural de¬ 
sign can be saved along with the language- 
independent version. 


Automated support for 
OOSD 

Automated computer-aided software 
engineering (CASE) tools can support 
OOSD notation and enhance its usability 
by addressing not only the drawing of 
OOSD charts but also consistency check¬ 
ing, code generation, design reuse, and 
comprehensibility. 

Consistency checking. Consistency 
checking makes certain that a design is 
complete and consistent. Design rule 
checking can include many tests, including 
verifying that names are used consistently, 
that a module or operation’s parameters 
are consistent, and that all connections 
between elements in the chart are valid. 

For example, when two symbols are 
connected, a graphical editor can deter¬ 
mine the validity of the connection and ask 
the user to select the type of connection, 
such as “call” or “lexical inclusion,” so 
that valid architectural structures can be 
created for various programming lan¬ 
guages. 

Code generation. We designed OOSD 
notation to support the immediate genera¬ 
tion of syntactically and semantically cor¬ 
rect program units,, so detailed design in¬ 


formation or source code can be associated 
with each symbol. 

Note that every class or subprogram unit 
in OOSD includes not only a complete 
specification of its interface but also infor¬ 
mation about its connections to and visibil¬ 
ity from other program units. Each graph¬ 
ical component can then have associated 
declarative or procedural information 
added through an annotation mechanism 
that provides a language-specific template 
for each symbol in an OOSD chart. This 
detailed design and algorithmic informa¬ 
tion is not usually available during archi¬ 
tectural design but is added later. 

Language-specific code-generation 
rules are integrated with design-checking 
rules and printing routines through a data 
dictionary, so source programs (or units) 
can be produced as text files and sent to 
checkers or compilers as appropriate. The 
data dictionary is a repository for the archi¬ 
tectural design, the detailed design, and the 
source code. 

Reuse. A principal goal of object-ori¬ 
ented design methods is the reuse of class 
definitions and other parts of existing de¬ 
signs. Automated support for reusability is 
provided through a reuse library. The reuse 
library is a controlled library that can 
contain any validated design or code com¬ 
ponent. For example, a reusable compo¬ 
nent might be the generic table in Figure 5 
or the buffering monitor in Figure 10, 
complete with formal specifications of its 
behavior and validated source code for the 
monitor’s implementation. 
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Automated support for reuse provides 
not only the reuse library but also a browser 
whereby designers can search the library 
for useful components and a mechanism 
for using selected components. The reuse 
facility must support both a reference to a 
component in the reuse library and the 
ability to copy and modify that component 
outside the library, with the resulting 
modified component becoming a candi¬ 
date for addition to the library. The facility 
must also support the object-oriented para¬ 
digm, reusing components through inheri¬ 
tance, and instantiation. 

Comprehensibility. Although OOSD 
notation is intended to be simple, designs 
for large systems can become quite com¬ 
plex, since there can be a large number of 
program units (modules, classes, moni¬ 
tors), and each can have many dilferent 
interfaces and be connected to many other 
program units. Accordingly, automated 
support must let designers not only navi¬ 
gate a design that is represented in numer¬ 
ous separate diagrams but also hide and 
show levels of detail as needed. For ex¬ 
ample, a designer could select a class 
symbol (as in Figure 13), go to an ex¬ 
panded representation of the class showing 
all the operations and their interfaces, and 
then go to an expanded representation of 
an individual operation, message, or other 
design component. In short, the automated 
support must help the designer manage the 
complexity of designs by supporting 
modularity and information hiding in the 
design itself. 

An OOSD design environment. These 
capabilities are part of an integrated design 
environment that can effectively support 
OOSD. When these capabilities are sup¬ 
plemented by complementary tools for 
analysis and a suitable programming envi¬ 
ronment that supports the later stages of 
software development, the result is a 
comprehensive CASE environment. 

We are developing these OOSD facili¬ 
ties as an extension to the Software through 
Pictures environment. 12 A graphical editor 
for OOSD is configured for a particular 
programming language by associating a 
set of language-specific templates with the 
editor. In this way, the appropriate set of 
detailed design symbols can be included, 
and code can be produced for the given 
language. For example, a language-spe¬ 
cific editor, such as the OOSD/Ada Design 
Editor, linked with a structured editor and 
an Ada programming environment (com¬ 
piler, linker, debugger, etc.) produces an 
OOSD development environment for Ada. 


T he OOSD design notation synthe¬ 
sizes ideas from several sources. 
We have found OOSD very effec¬ 
tive for representing both sequential and 
concurrent designs of varying sizes and 
with different target programming lan¬ 
guages. As a result, we believe OOSD can 
be a standard design representation for 
software systems, serving the same pur¬ 
pose for software designs as schematics 
and block diagrams for electrical engineer¬ 
ing and overcoming a significant short¬ 
coming of software engineering. 

OOSD notation accommodates differ¬ 
ent design styles, allowing designers to 
follow either a functional or an object- 
oriented approach. We expect that design¬ 
ers will gradually evolve from a top-down, 
functional decomposition approach to an 
object-definition approach. 

Future work will focus on five areas: 

(1) determining appropriate analysis 
methods that can integrate with 
OOSD; 

(2) developing object-oriented design 
methods; 

(3) defining design quality measures 
for OOSD designs; 

(4) extending Software through Pic¬ 
tures to provide better support for 
OOSD and code generation as part 
of an integrated toolset; and 

(5) building libraries of reusable de¬ 
signs in OOSD. ■ 
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W henever a domain of study or 
practice contains many distinct 
objects, the problem of classi¬ 
fication arises. Classification means parti¬ 
tioning the objects into a structured set of 
classes on the basis of meaningful criteria. 
A taxonomic system (or, synonymously, a 
classification scheme) is a system of rules 
whereby objects in a given domain are 
classified in a particular way.* 

The best known and most highly devel¬ 
oped taxonomic system is probably the 
Linnaean system for plants and organisms, 
first developed by an eighteenth-century 
Swede, Carl Linnaeus. In fact, biological 
classification schemes date back to ancient 
Greece. 1 Another celebrated classification 
scheme from the natural world is the peri¬ 
odic table for chemical elements, first set 
forth simultaneously and independently in 
1869 by Lothar Meyer in Germany and 
Dimitri Mendeleev in Russia. 2 However, 
the world of artifacts also has its taxo¬ 
nomic systems (albeit much more rudi¬ 
mentary) as represented, for example, by 
various schemes for classifying building 
types. 3 


*The word taxonomy, strictly speaking, refers to the 
theory, practice, and science of classification. How- 
ever, it is often used loosely as a synonym for classifi- 
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Using formulas 
inspired by chemical 
notation, we can 
classify computer 
architectures in a way 
that provides both 
predictive power and 
explanatory 
capabilities. 


This article concerns the development 
of taxonomic systems for computer archi¬ 
tectures. Several points of immediate in¬ 
terest deserve attention. First, the objects 
to be classified are abstract entities — spe¬ 
cifically, those abstract characteristics that 
collectively constitute a computer’s archi¬ 
tecture. Of course, since every “physical” 
computer possesses an architecture, any 
taxonomic scheme for architectures will 
also, in effect, be a system for classifying 
physical computers. 

0018-9162/90/0300-0064$01.00 © 1990 IEEE 


Second, in discussing computer archi¬ 
tectures, it is important to understand the 
abstraction level at which they are being 
considered. In particular, architects distin¬ 
guish between the outer architecture of 
computers — the logical structure and 
behavior of systems as seen by the com¬ 
piler writer or systems programmer — and 
their inner architecture—the logical struc¬ 
ture, control, and behavior of the inte¬ 
grated system of hardware components. 
Elsewhere, I have referred to these as 
exoarchitecture and endoarchitecture , re¬ 
spectively. 4 The former consists of such 
components as the externally visible stor¬ 
age hierarchy, the instruction set, the in¬ 
struction formats, and the addressing 
modes. The latter concerns the nature of 
the instruction (interpretation and execu¬ 
tion) cycle, the internal organization of and 
the relationships between storage compo¬ 
nents and functional units, and the means 
by which instruction processing is con¬ 
trolled. 

The discussion of architectural taxon¬ 
omy in this article is wholly confined to the 
endoarchitectural level. This is certainly 
not because exoarchitectures are unimpor¬ 
tant. Rather, while a truly comprehensive 
taxonomic scheme should encompass both 
exo- and endoarchitectures, it is nonethe¬ 
less meaningful and often convenient to 
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separate them and construct taxonomic 
schemes for each level independently. 

Third, even if we were to agree with the 
commonly expressed sentiment that most 
computer architectures are merely vari¬ 
ations on a single, small set of principles 
established in the 1940s, there are so many 
of these variations and they have generated 
such a diversity of large and distinct archi¬ 
tectures that they demand a system of clas¬ 
sification. Just as the cumulation of small 
genetic mutations gave rise to so many 
distinct organisms, so miniscule variations 
on the so-called “von Neumann” theme 
have resulted in a proliferation of distinct 
architectures. The urge, or need, to classify 
computer architectures is thus compelling. 

Several general classification schemes 
for computer architectures have been pro¬ 
posed in the past few decades, 5 ' 11 and I 
recently reviewed many of them. 4 Signifi¬ 
cantly, they all fail to satisfy one or more of 
the fundamental goals and characteristics 
of “good” taxonomic systems. The next 
section will discuss these desirable charac¬ 
teristics. 

Of all the systems cited above, Flynn’s 
is undoubtedly the best known. In spite of 
its deficiencies, 4 it continued to serve as 
the most popular classificatory framework 
for architectures chiefly because no really 
satisfactory alternative had been devised. 
However, the taxonomic system recently 
proposed by Skillicom 12 represents a very 
real improvement in the development of 
mature and “good” architectural taxon¬ 
omy. Nevertheless, Skillicorn’s system 
still falls short in a number of ways, as we 
will see. 

This article’s main objective is to pre¬ 
sent a new, hierarchical architectural taxo¬ 


nomic system that appears to possess the 
desirable characteristics of a good taxo¬ 
nomic scheme (as enunciated in the next 
section). The starting point for this system 
is Skillicom’s scheme. However, we will 
see that this system both extends and de¬ 
parts from Skillicom’s scheme in wholly 
distinct and novel ways. The influence of 
the conceptual framework underlying 
chemical notation will also be evident. 

Taxonomic systems: 
basic terms and 
characteristics 

Given a set of objects we wish to clas¬ 
sify, the simplest of taxonomic systems 
must consist of a single set of taxons among 
which we can partition the objects. A taxon 
is a named group of objects that are suffi¬ 
ciently distinct (with respect to a specific 
set of properties) from the objects belong¬ 
ing to some other taxon. The set of such 
taxons constitute a category 4 The set of 
properties that determine how objects are 
assigned to the various taxons are termed 
taxonomic characters (TCs). 

In more comprehensive classification 
schemes, several categories can be identi¬ 
fied, each with its own set of taxons. These 
categories can be ranked in a hierarchy. 
Each object would appear in exactly one 
taxon in each category. 

Once a classification scheme has been 
constructed, we must be able to refer to the 
categories and the taxons. Thus, a taxo¬ 
nomic system must contain a convenient, 
methodical, and meaningful system of 
nomenclature. 


Figure 1 shows, in general form, the 
structure of a typical hierarchical taxo¬ 
nomic scheme in which the category i is at 
a higher rank than category i + 1. 

Hierarchical classification systems by 
their very nature exhibit some particularly 
attractive properties. They not only pro¬ 
vide a basis for comparing and discrimi¬ 
nating between objects, but they also make 
it possible to determine the points of their 
convergence to a common taxon (or diver¬ 
gence into two or more taxons) across 
category levels. Thus they provide a con¬ 
ceptually more elegant picture of the tela- 
tionships between objects than do nonhier- 
archical schemes. 

There are several reasons for developing 
a classification scheme. 4 The simplest (and 
least interesting) is that it provides a basis 
for information ordering as needed, for 
example, for cataloging documents on 
computer architectures in a library or for 
organizing architectural descriptions in a 
textbook. 

A more useful role, already mentioned, 
is to establish a theoretical framework 
within which we can meaningfully com¬ 
pare and discriminate between architec¬ 
tures and determine precisely how and 
where they converge or diverge. 

More interesting is for a classification 
scheme to provide a foundation for pre¬ 
dicting certain properties of an architec¬ 
ture. Specifically, given a taxonomic sys¬ 
tem, and being informed that architecture 
A belongs to taxon y in category x, we 
should be able to infer properties or char¬ 
acteristics of A from our knowledge of the 
taxonomic system. 

A stronger and more ambitious version 
of the predictive role is for the classifica- 
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Table 1. A fragment of Skillicorn’s taxonomy. 


Taxon 

(class) 

nlP 

nDP 

IP-DP 

TCs 

IP-IM 

DP-DM 

DP-DP 

Name 

4 

0 

n 



nxn 


Tightly coupled dataflow 

6 

1 

1 

1-1 

1-1 

1-1 


von Neumann uniprocessor 

8 

1 

n 

l-« 

1-1 

n-n 

nxn 

Type 1 array processor 

9 

1 

n 

1 -n 

1-1 

nxn 


Type 2 array processor 

13 

n 

n 

n-n 

n-n 

n-n 


Separate von Neumann uniprocessors 

14 

« 

n 

n-n 

n-n 

n-n 

nxn 

Loosely coupled von Neumann 

15 

n 

n 

n-n 

n-n 

nxn 


Tightly coupled von Neumann 

21 

n 

n 

nxn 

n-n 

n-n 



24 

n 

n 

nxn 

n-n 

nxn 



28 

n 

n 

nxn 

nxn 

nxn 

nxn 



tion scheme to provide a basis for explana¬ 
tion. This can be facilitated if the taxo¬ 
nomic characters used to design the cate¬ 
gory/taxon system are the consequences of 
deeper, more fundamental causes. The 
distinction between predictive and ex¬ 
planatory goals is often subtle and largely 
a matter of degree. Given a taxonomy, and 
being informed that architecture A belongs 
to taxon y in category x, the predictive 
power of the scheme will allow us to infer 
that A has such and such properties. The 
explanatory power of the scheme, if at all 
present, will allow us to deduce why A 
possesses these properties. 

Clearly, constructing a taxonomic sys¬ 
tem with explanatory power is more diffi¬ 
cult than building one with predictive 
power only. Yet, as I’ve discussed else¬ 
where, 4 even the predictive power is quite 
limited in many of the architectural taxo¬ 
nomic schemes proposed so far. 

The precise nature and power of a taxo¬ 
nomic system will depend on the goals of 
the taxonomist. In the system to be pro¬ 
posed, the motivation is threefold: first, to 
establish a classification scheme within 
which the position of architectures relative 
to one another can be understood; second, 
as a foundation for constructing an archi¬ 
tectural knowledge base as part of a com¬ 
puter-aided design system; and finally, as 
a long-term objective, the construction of a 
comprehensive, comparative atlas of com¬ 
puter architectures within the unified 
framework of the taxonomy. 

A good taxonomic system should at least 
exhibit substantial predictive power; bet¬ 
ter yet, it should possess explanatory capa¬ 
bilities. If multiple categories are mean¬ 


ingful in the context, then the set of catego¬ 
ries should be chosen to form a hierarchy. 
The hierarchical taxonomic scheme would 
be such that a given object would occupy 
exactly one taxon in each category and the 
number of taxons would decrease as we 
ascend the hierarchy of categories (see 
Figure 1). The scheme should contain a 
nomenclature so that the categories and 
taxons can be meaningfully and systemati¬ 
cally named. 

Skillicorn’s scheme 

Skillicom' 2 recently proposed a scheme 
that in many ways is better than any of the 
earlier proposals. The Skillicom scheme, 
couched in the terminology introduced 
above, can be summarized as follows: 

(1) Six taxonomic characters (TCs) are 
used: 

• the number of instruction processors, 
denoted nlP; 

• the number of data processors, denoted 
nDP; 

• the switch connecting one or more IPs 
with one or more DPs, denoted IP-DP; 

• the switch connecting one or more IPs 
with one or more instruction memo¬ 
ries, denoted IP-IM; 

• the switch connecting one or more DPs 
with one or more data memories, de¬ 
noted DP-DM; and 

• the switch connecting DPs, denoted 
DP-DP. 

(2) The possible values for the TCs nlP 


and nDP are, obviously, integers. For the 
switches, the possible values are desig¬ 
nated as “none,” “n-n,” and “nxn." An n-n 
IP-IM switch, for example, signifies a 
dedicated connection between each of n 
(IP,IM) pairs. An nxn DP-DM switch, on 
the other hand, signifies a common 
(shared) switch connecting n DPs to n 
DMs. Special cases of the n-n value are 
denoted as 1-1 and 1-n, with obvious inter¬ 
pretations. 

(3) The critical and most complex 
components in this scheme are the con¬ 
cepts of the instruction processors and the 
data processors. Skillicom precisely de¬ 
fines these concepts in terms of the set of 
functions each performs. Thus, an IP 

• determines the address of the next 
instruction to be executed on the basis 
of local state information and the state 
information passed to it by the DP; 

• accesses the IM to fetch the instruc¬ 
tion; 

• receives and decodes the fetched in¬ 
struction; 

• informs the DP of the operation to be 
performed; 

• determines the operand addresses and 
passes them to the DP; and 

• receives the state information from the 
DP after the latter has executed the 
operation. 

By its definition, a DP 

• receives the operation to be performed 
from the IP; 

• receives operand addresses from the 
IP; 
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• fetches operands from the DM; 

• executes the operation; 

• stores results in the DM; and 

• returns state information to the IP. 

(4) Using the six TCs — two denoting 
the number of processors and four the types 
of switches — Skillicorn established a 
single category of 28 taxons, each of which 
he called and numbered as a class. To some 
of these classes he also assigned a more or 
less familiar name. Table 1 reproduces a 
small fragment of his resulting taxonomy. 

(5) The above-mentioned classification 
clearly describes computers at the endo- 
architectural level, though Skillicorn re¬ 
ferred to this as the description of “abstract 
machines.” At a lower level of abstraction, 
Skillicorn characterized the sequencing 
and ordering operations performed by 
specific IPs and DPs in terms of state dia¬ 
grams and used these diagrams to distin¬ 
guish between pipelined and nonpipelined 
processors. These state diagrams, how¬ 
ever, play no part in the taxonomy outlined 
above. 

A critique of 
Skillicorn’s scheme 

Skillicom’s scheme improves consid¬ 
erably not only on Flynn’s taxonomy but 
also on the Hwang-Briggs modification to 
that taxonomy. 10 Skillicorn went to con¬ 
siderable length to show how familiar 
architectural styles can fit into his scheme 
— as the names in the rightmost column of 
Table 1 indicate. Thus, it would appear that 
given his 28 taxons (classes), the main role 


of his system is to provide place holders for 
architectures having known TC values. 
Skillicorn’s scheme offers conceptual 
simplicity and is very easy to apply, but it 
has some important limitations. 

The first limitation is predictive power. 
Suppose we are informed that architecture 
A is a class 14 architecture. Our knowledge 
of the scheme would then allow us to pre¬ 
dict the values of the TCs corresponding to 
this taxon. To this extent the scheme has 
predictive power. However, neither the 
scheme nor its nomenclature allows us to 
infer to what extent or at what level two or 
more architectures belonging to distinct 
classes are similar, or the extent to which 
different architectures from a single com¬ 
puter family are similar, without actually 
comparing the values of the respective 
TCs. This is because Skillicom’s system 
has only one category and, consequently, 
is nonhierarchical (more on this in a 
moment). 

Explanatory power is the second limita¬ 
tion. Had the notion of explanation as a 
desirable system characteristic been con¬ 
sidered explicitly, the significance of the 
various TCs and their possible values 
would probably have been more carefully 
delineated. As a result, Skillicorn’s 
scheme, as given, has little overt explana¬ 
tory power. However, given the precise 
characterization of IP and DP, this scheme 
has considerable potential , or latent, ex¬ 
planatory capabilities. 

The scheme does not include the impor¬ 
tant concept of pipelining at the same ab¬ 
straction level at which memories, proces¬ 
sors, and switches are taken into account. 
Thus, pipelining as a TC does not appear in 


the taxonomy depicted in Table 1. Pipelin¬ 
ing is considered, but only at the lower 
state-diagram level referred to earlier. 
Skillicorn implied that the two levels (the 
abstract machine and the state diagram) 
form a hierarchy. In fact, his system is not 
hierarchical in the sense we discussed 
previously and as exemplified by Figure 1. 

To begin with, the state diagrams are not 
formally identified as a collection of dis¬ 
tinct taxons and thus do not constitute a 
proper category (only some representative 
examples of particular state diagrams are 
presented). To the extent that any distinct 
taxons exist at the state diagram level, 
these are confined to the taxons “simple 
IP,” “pipelined IP,” “simple DP,” and 
“pipelined DP.” Secondly, these taxons do 
not relate hierarchically to the taxons at the 
higher (abstract machine) level, as we can 
see from Figure 2. There are more taxons at 
the higher level than at the lower level. 
Furthermore, the same taxon (for example, 
pipelined IP) at the lower (state diagram) 
level can be contained in and shared by two 
or more taxons at the higher level. We can 
legitimately conclude that the two levels 
are actually orthogonal to each other rather 
than hierarchically related. 

Although the IM and DM components 
are said to be memory hierarchies, this fact 
plays no part in the classification scheme. 
Skillicorn concerned himself with estab¬ 
lishing a system that discriminates among 
the various parallel-processing and mul¬ 
tiple-processing architectures. Yet the 
distinction between main and cache mem¬ 
ory and the significant presence of the 
latter in multiprocessing systems are ig¬ 
nored in his scheme. 
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A new hierarchical 
taxonomic scheme: 
basic concepts 

The rest of this article describes a new 
hierarchical taxonomic system that takes 
Skillicom’s scheme as a starting point but 
addresses its limitations and thereby de¬ 
parts radically from it. The resulting taxo¬ 
nomic system is, I believe, quite novel in 
its structure. Rather than engage in prior 
justification of its contents, let us explore 
the scheme systematically and see how it 
can be employed. Its justification and 
advantages should emerge directly from 
this exercise. 

The taxonomy is built from seven primi¬ 
tive endoarchitectural concepts referred to 
as atoms. These atoms constitute the taxo¬ 
nomic characters for the taxonomy. Atoms 
of the same type can be combined into 
more complex entities called atomic radi¬ 
cals, which in turn can be combined into 
still more complex concepts called non- 
atomic radicals. Finally, nonatomic radi¬ 
cals are combined into molecules, which 
denote entire endoarchitectural entities. 

Characterizing certain types of architec¬ 
tural concepts as “primitive” and then call¬ 
ing them “atoms” merely means that in the 
. context of the abstraction level of interest 
— the endoarchitectural level — these 
concepts are viewed as atomic, or primi¬ 
tive. If we were to construct a taxonomy 
for systems at the register transfer or logic 
level, these same concepts would have an 
internal structure and thus not be the atoms 
of interest. This is an obvious property of 
hierarchical systems. 


The basic entities, 
or atoms, in the 
proposed taxonomy 

iM: interleaved memory 
sM: simple memory 
C: cache 

si: simple (or single-stage) in¬ 
struction preparation unit/ 
processor 

pi: pipelined instruction prepa¬ 
ration unit/processor 
sX: simple (or single-stage) 
execution unit/processor 
pX: pipelined execution unit/ 
processor 


Atoms. The symbols iM, sM, C, si, pi, 
sX, and pX identify the atoms (the basic 
entities) in the proposed taxonomy (see 
sidebar). For convenience, I will use these 
symbols to designate both the identifiers of 
the atoms and the atoms themselves. The 
uppercase letters M, C, I, and X are termed 
ions (of their respective atoms), and the 
lowercase letters s, i, and p are termed the 
prefixes (of their respective ions). 

M stands for a main memory module 
(for instructions or data). The atomic 
symbol sM denotes a simple module and 
represents a potential for a unit of informa¬ 
tion (byte, word, or multiple byte) to be 
accessed from main memory per memory 
cycle. The atomic symbol iM denotes an 
interleaved memory module and repre¬ 
sents a potential for multiple units of infor¬ 
mation to be accessed from main memory 
per memory cycle. 

C stands for a programmable or nonpro¬ 
grammable cache (holding instructions or 
data). The cache’s function is to decrease 
memory latency when information (in¬ 
structions or data) in main memory must be 
accessed. A nonprogrammable cache is a 
cache in the conventional sense — that is, 
a high-speed store automatically loaded 
with information from main memory by 
the hardware according to some cache¬ 
loading policy and to which the program¬ 
mer has no access. A programmable cache 
is a high-speed store explicitly loaded 
under program control with information 
from main memory such that information, 
when required, is “mostly” found in the 
cache. (The concept of a cache atom, C, 
then, includes large files of processor reg¬ 
isters, as in the Cray-1 or in some RISC 
machines.) 

I stands for an instruction preparation 
unit, whose function is defined by the fol¬ 
lowing set of operations: 

• Determine the next instruction to be 
executed. 

• Fetch the instruction from M or C (in 
this context, M and C are instruction M 
and instruction C). 

• Decode the instruction. 

• Compute the effective address of the 
operands. 

• Transfer the operand addresses and the 
operation to the instruction execution 
unit (see below). 

• Receive the state information from the 
execution unit. 

An I represents a processing unit capable 
of instruction preparation. The symbol si 
represents a processing unit I in which a 


single instruction can be prepared at a time 
— that is, only one instruction can be in I 
at any given time. The symbol pi repre¬ 
sents an I in which several instructions 
can be prepared (contained) at a time. 
Thus, a pi signifies a potential for increas¬ 
ing the throughput of instruction prepara- 

X stands for an instruction execution 
unit, or processor, whose function is de¬ 
fined in terms of the following set of opera- 


• Receive operand addresses and opera¬ 
tion from I. 

• Fetch operands from M or C (in this 
context, M and C are data M and data 
C). 

• Carry out the operation. 

• Store the result in M or C. 

• Return state information to I. 

An X represents a processing unit capable 
of instruction execution. The atomic sym¬ 
bol sX represents an X that can execute 
only a single instruction at a time — that is, 
only one instruction can be in X at any 
given time. The atomic symbol pX repre¬ 
sents an X with the potential for executing 
(and containing) several instructions at a 
time. 

Except for the fact that operands can be 
fetched from, and results stored in, cache, 
X is functionally identical to Skillicom’s 
DP. Similarly, except for the fact that in¬ 
structions can be fetched from cache, I is 
functionally identical to Skillicom’s IP. 

Atomic radicals. Given an atom A, a 
replicated instance of it is denoted as A k or 
A n , where k >1 is an integer constant and n 
is a positive integer-valued variable. Thus, 
for example, iM,, sM 4 , and C g denote two, 
four, and eight atoms of interleaved mem¬ 
ory, shared memory, and cache, respec¬ 
tively, while pl m denotes m (an unspecified 
number of) instances of an instruction 
preparation unit. 

A replicated atom is termed an atomic 
radical. The subscript is termed the radical 
number. When RN is 1, the radical is obvi¬ 
ously identical to the corresponding atom 
and is referred to as a monoatomic radical. 
In this case the RN may simply be omitted 
— for example, C, and C are equivalent. 
When RN > 1, the radical is called a multi- 
atomic radical. 

A multiatomic memory radical (M-radi- 
cal) — for example, iM 4 , sM n — represents 
a potential for multiple memory modules 
to be accessed in parallel or independently. 
The larger the value of RN, the greater the 
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potential bandwidth of information trans¬ 
fer from memory. 

A multiatomic cache radical (C-radical) 
— for example, C 4 , C n — similarly repre¬ 
sents multiple cache memories with the 
potential to be referenced in parallel or 
independently. The greater the value of 
RN, the greater the potential for decreasing 
overall memory latency. 

A multiatomic instruction preparation 
unit radical (I-radical) — for example, sl 4 , 
pl t — signifies a potential for several in¬ 
struction streams to be prepared in parallel 
or independently. Moreover, it implies a 
commitment toward both reducing a single 
program’s total processing time and in¬ 
creasing the throughput of a multiple-pro¬ 
gram work load. It also implies a potential 
for fault tolerance. 

A multiatomic instruction execution 
unit radical (X-radical) — for example, 
sX 2 , pX n — signifies a potential for in¬ 
structions from several instruction streams 
to be executed in parallel or independently. 
Otherwise, it has the same implications as 
an I-radical. 

Complex, or nonatomic, radicals. A 

cache-processor (CP-) radical is a combi¬ 
nation of a C-radical with an I-radical, an 
X-radical, or another CP-radical such that 
the combination itself constitutes a radical. 
By convention the C-radical must be to the 
left of the radical with which it is being 
combined. When RN > 1 for the CP-radi- 
cal, the combination is enclosed in paren¬ 
theses. Examples are C.sl, (C.pX) n , 
C m .sX n , and C.(C 2 .pI) 2 . 

A memory-cache processor (MCP-) 
radical is a combination of an M-radical 
with an I-radical, an X-radical, a CP-radi- 
cal, or another MCP-radical where the 
combination itself constitutes a radical. By 
convention the M-radical must be to the 
left of the radical with which it is being 
combined. As above, when RN > 1 for the 
MCP-radical, the combination is enclosed 
in parentheses. Examples are (iM) m . 
(C.pl) n , iM.(C.sI 2 ) t , iM.(sM.C.sI) m , and 
sM.M.C.pK 

Molecules. An I-molecule is an MCP- 
radical that represents a complete instruc¬ 
tion preparation subsystem within a com¬ 
puter at the endoarchitectural level. 

An X-molecule is an MCP-radical that 
represents a complete instruction execu¬ 
tion subsystem within a computer at the 
endoarchitectural level. 

A macromolecule is a single or a repli¬ 
cated combination of an I-molecule and an 
X-molecule that represents a complete 


Table 2. Syntax of radicals and molecules. 


M' 

c 

V 

X' 

CP' 

MCP' 


iM I sM I iM n I sM n 
ClC 

si I pi I Sl n I pi 
sX I pX I sX n |pX n 

c'.r I c'.x' I c'.cp' I (cp)' b 

M'.I' I M'.X' I M'.MCP' I (MCP)'„ 


I" ::= MCP' 

X" ::= MCP' 

MM" ::= (I")(X") I ((I")(X"))„ 


Legend 

Atoms 

Replicated atoms 
(■)„ 


iM, sM, C, si, pi, sX, pX 

iM n , sM n , si,, pl„, sX„, pX„ (n = a variable or a constant) 
Replicated radical or molecule (n = a variable or a constant) 
Radical 
Molecule 


computer at the endoarchitectural level. 
By notational convention the I-molecule 
appears to the left of the X-molecule. 

Syntax. We now have all the basic 
symbols and concepts necessary for our 
taxonomic system. Table 2 summarizes in 
BNF-style notation the syntax of the 
atomic and complex radicals and the mole¬ 
cules. The primitive symbols sM, iM, C, si, 
pi, sX, and pX represent the seven types of 
atoms. Single primes denote radicals, 
while double primes signify molecules. 

The structure of radicals and mole¬ 
cules. Extending the chemical metaphor 
further, the symbol string describing a 
particular radical or molecule is referred to 
as a formula. The structure of each radical 
or molecule can be shown explicitly by 
parsing the formula according to certain 
structural rules defined as follows: 

Let R signify a radical in formula form. 
Let head(R) and tail(R) denote, respec¬ 
tively, the largest leftmost radical and the 
largest rightmost radical in R. For ex¬ 
ample, given the radical R1 = C.sl, 
head(Rl) = C, tail(Rl) = si; given R2 = 
(C.pl)„, head(R2) = tail(R2) = (C.pl) n ; 
given R3 = iM m .(C.pI)„, head(R3) = iM m , 
tail(R3) = (C.pl)„. 

The structure of a radical (or, by impli¬ 
cation, of an I or an X molecule) can be 
determined by using two primitive opera¬ 
tors, Rep and Link, defined as follows: 

(1) Let R be a radical. Then the operator 
Rep(R) causes the structure 


R 


R 

to be produced. 

(2) Let Rl, R2 each signify a radical 
(but not a macromolecule) in formula 
form. Then the operator Link(Rl,R2) 
causes the following structures to be pro¬ 
duced: 

If tail(Rl), head(R2) are both nonrepli- 
cated, then the simple link 

R-R 

If tail(R 1) is nonreplicated but head(R 1) is 
replicated and of the form Zn, then the 
right divergent link 



If tail(Rl) is replicated and of the form Wn 
but head(R2) is nonreplicated, then the left 
divergent link 



W 


If tail(R 1) is replicated and of the form Wn 
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Table 3. Structure rules. 


(1) 

St(M') 

= 

if iM then iM 
if sM then sM 
if iM n then Rep(iM) 
if sM n then Rep(sM) 

(2) 

St(C') 

= . 

if C then C 
if C„ then Rep(C) 

(3) 

st(i') 


if si then si 
if pi then pi 
if sl n then Rep(sl) 
if pl n then Rep(pl) 

(4) 

St(X') 


if sX then sX 
if pX then pX 
if sX n then Rep(sX) 
if pX n then Rep(pX) 

(5) 

St(CP') 


if C'.I' then Link(St(C'), St(I')) 
if C'.X' then Link(St(C'), St(X')) 
if C'.CP' then Link(St(C'), St(CP')) 
if (CP')„ then Rep(St(CP')) 

(6) 

St(MCP') 


if MM'then Link(St(M'), St(I')) 
if M'.X' then Link(St(M'), St(X')) 
if M'.CP' then Link(St(M'), St(CP')) 
if M'.MCP' then Link(St(M'), St(MCP')) 
if (MCP')„ then Rep(St(MCP')) 

(7) 

st(D 

= 

St(MCP') 

(8) 

St(X") 

= 

St(MCP') 

(9) 

St(MM") 

= 

if (I")(X") then St(I") I St '(X") 


if ((I")(X"))„ then Rep(St(I") I Sr‘(X")) 


and head(R2) is replicated and of the form 
Zm, then the bidivergent link 



Using Rep and Link, the structure corre¬ 
sponding to any formula other than that of 
a macromolecule can be determined ac¬ 
cording to rules 1 through 8, shown in 
Table 3. Here St(x) is an abbreviation for 
structure of x, while Sr'(x) denotes the 
mirror image of the structure of x. 

Before examining rule 9 in Table 3, for 
molecules, it is important to understand 
exactly what each type of link generated by 
Link represents. A simple link between 
radicals R1 and R2 signifies a dedicated 
path between R1 and R2. A right divergent 
link between R1 and R2 indicates a shared 
path between R1 and the replicated in¬ 
stances of R2. A bidivergent link between 
R1 and R2 represents a shared path be¬ 
tween all the replicated instances of R1 and 
all the replicated instances of R2. 

In contrast to radicals, however, a 


macromolecule formula (I")(X") is merely 
a convenient juxtaposition of two MCP 
radicals; no paths or links are implied by 
such a juxtaposition. Hence, the structure 
of a macromolecule (rule 9 in Table 3) is 
defined by a vertical dashed line separat¬ 
ing the structures of the I and X molecule 
components. 

Figure 3 shows the formulas for some 
representative radicals and molecules and 
the corresponding structural forms. Note 
that while formulas exhibit radical num¬ 
bers, the structures do not. 

It is clear from the foregoing discussion, 
and especially from Table 3 and Figure 3, 
that switches in Skillicorn’s sense are 
implicit in the formulas and are rendered 
explicit in the corresponding structures. 

Hierarchical 
categories of the 
taxonomic system 

There are three principal hierarchically 
related categories in our classification 
scheme. 


(1) At the lowest rank is the molecular 
(MCP) category. All possible distinct 
macromolecules constitute the taxons of 
this category. Each taxon’s name at the 
molecular rank is simply the correspond¬ 
ing molecular formula. 

(2) At the next-higher rank is the cache 
processor (CP) category. The set of taxons 
in this category (and the corresponding 
names) is obtained from the taxons in the 
molecular category by eliminating the M- 
radicals and retaining the CP-radicals. 

(3) At the highest rank is the processor 
(P) category. The taxons in this category 
are obtained from the taxons in the CP 
category by eliminating the C-radicals and 
retaining the remaining P-radicals. 

An example illuminates the nature of the 
three categories. Figure 4 shows where 
three related computers, the VAX 8600, 
the VAX 11/780, and the VAX 11/750, 
stand in the proposed scheme. At the mo¬ 
lecular level, they belong to three distinct 
taxons given by the respective molecular 
formulas. At the CP level the 780 and 750 
fall into the same taxon — (C.pI)(C.sX) — 
while the 8600 is in a different taxon, 
(C.pI)(C.pX). At the P level the 780 and 
750 obviously remain in the same taxon, 
while the 8600 occupies a different taxon. 

The power of the 
proposed system 

To assign a computer a place in this 
system, we must first establish a molecular 
formula for the computer’s endoarchitec- 
ture. The formula, once established, con¬ 
stitutes the computer’s taxon at the mo¬ 
lecular level. This may turn out to be a 
wholly new taxon, or it may be identical to 
a previously established taxon that already 
contains other computers. 

Let us look at the significance of each 
category. 

The molecular category. A molecular 
formula (or the corresponding structure) 
conveys considerable information about a 
computer. It specifies a computer’s com¬ 
position in terms of memory, cache, and 
the two types of instruction processing 
units; it specifies whether memory is inter¬ 
leaved or not, whether the processing units 
are simple or pipelined, and whether cache 
is used to hold instructions, data, or both. 
Furthermore, it specifies whether there are 
one or more memories, caches, and pro¬ 
cessing units, as well as the nature of the 
interconnections between them. 


70 


COMPUTER 









We can extract all this architectural in¬ 
formation directly from the name of the 
taxon, that is, from the formula itself. Thus, 
the predictive power of the classification 
scheme at the molecular level lies in the 
way molecular formulas are established 
and the fact that these formulas constitute 
the names of the corresponding taxons. 

There is more to it, however. In intro¬ 
ducing the basic concepts of the proposed 
classification scheme, I also established 
the pragmatic significance of the various 
kinds of atoms and atomic radicals in terms 
of the architectural design objectives they 
are broadly intended to address. Thus, 
given a computer with a particular archi¬ 
tecture, we can infer from its molecular 
formula, or taxon, in very broad (and lim¬ 
ited) terms, the kinds of objectives that 
motivated the architectural design. To the 
extent that such objectives were the rea¬ 
sons for that particular architecture, and 
given that the molecular formula encapsu¬ 
lates the essence of the architecture, the 
formula allows us to explain why the 
computer has this formula, that is, why it 
falls into that particular taxon. 

As a specific example, consider the for¬ 
mula (iM.C.pI)(iM.C.pX) for the VAX 
8600. What does this tell us? From the 
monoatomic radicals pi and pX, we know 
that the machine is a uniprocessor system. 
From the prefix p to the I and X ions, we 
further infer that the entire instruction¬ 
processing cycle is pipelined. The double 
presence of the C- and iM-radicals further 
reveals that the flow through the pipelines 
is facilitated by a combination of inter¬ 
leaved memories and caches. (Note that 
such terms as uniprocessor and pipeline 
refer to categories or taxons from other, 
possibly disparate, taxonomic systems. In 
a sense, then, the predictive power of a 
classification scheme is the extent to which 
it allows us to map a variety of other clas- 


Category VAX 8600 VAX 11/780 VAX 11/750 

P (pl)(pX) 


CP (C.pl)(C.pX) 


Molecular (iM.C.pl)(iM.C.pX) 


Figure 4. The place of three VAXs in the proposed scheme. 


(pl)(sX) 

(C.pl)(C.sX) 



(IM.C.pl)(iM.C.sX) (sM.C.pl)(sM.C.sX) 
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Table 4. Molecular formulas for some well-known computers. 


Illiac IV : 

(sM 64 .sI)(sM.sX) 64 

Cray-1 : 

(iM.C.pI)(iM.C„.pX 9 ) 

Cray X-MP : 

(iM m .(C.pI) n )(iM m .(C.pX) ) 

Encore Multimax : 

(iM.(C.sI 2 ) t )(iM.(C.sX 2 ) t ) 

CM-2 Connection Machine : 

(iM.C.pI)(sM.sX) 64t 

AP-120B : 

(sM.sI)(iM.sM.pX 3 ) 

FPS-164 : 

(iM.C.sI)(iM.sM.pX 3 ) 

IBM 3838 : 

(sM.pI)(sM.pX 7 ) 

IBM RP3 : 

(iM.tsM.C.sI^XiM.tsM.C.sXj)^ 

TI ASC : 

(iM.pI)(iM.pX 4 ) 


sification schemes onto the given one.) 

In addition to this prediction of the 
computer’s architecture, we can infer the 
following: The VAX 8600 belongs to this 
particular molecular taxon because of the 
designers’ objective to establish a high- 
performance uniprocessor. The principal 
means to achieve high performance in a 
uniprocessor system include the use of 
interleaved memory to effect high memory 
bandwidth, caches to realize low memory 
latency, and pipelining to achieve high 
instruction throughput. The explanatory 
power of the scheme lies in its ability to let 
us make such inferences. 

The CP and P categories. The CP cate¬ 
gory is an abstraction of the molecular 
category. It identifies taxons such that two 
or more computers belonging to the same 
taxon in this category are architecturally 
identical except, possibly, in their memory 
components.* As with conventional us¬ 
age, the term processor includes both 
caches and processing units. The CP cate¬ 
gory classifies the architecture of such 
processors and thus contrasts with the 
molecular category, which classifies entire 
computers. 

Similarly, the P category is an abstrac¬ 
tion of the CP category and defines taxons 
such that two or more computers belong¬ 
ing to the same taxon in this category are 
identical in terms of their instruction 
preparation and execution units. Thus, the 


restricted in this context because we are confining our 
attention to (1) the endoarchitectural level and (2) a 
characterization of this level solely in terms of the 
architectural components explicitly recognized in this 
classification scheme. 


P category classifies the architecture of 
computers according to their actual pro¬ 
cessing elements, disregarding the mem¬ 
ory and cache components. 

Other categories. Just as the Linnaean 
system with its seven categories has on 
occasion been extended with additional 
intermediate categories (for example, the 
subspecies or the superfamily categories), 
the set of basic categories proposed here 
can be extended, too. Suppose, for ex¬ 
ample, we have identified two taxons at the 
P level with the formulas (pI)(pX 4 ) and 
(pI)(pX 9 ). Then we can establish a further 
category beyond P — call it “Ultra P” — 
that abstracts from the radical numbers and 
simply identifies architectures according 
to the nature of the I and X atoms. Archi¬ 
tectures falling into the above taxons in the 
P category would fall into the same taxon 
(pI)(pX) at the Ultra P level. In fact, at the 
Ultra P level there would be only four 
possible taxons: (sI)(sX), (sI)(pX), 
(pD(sX), and (pI)(pX). 

As another example, a category between 
the molecular category and the CP cate¬ 
gory can be meaningfully conceived in 
which the s or i prefix of the M atom is 
abstracted away, although the M ion is 
retained. The resulting category can be 
called the MionCP category. Consider, 
for instance, two molecules (sM.C.sI) 
((iM.pX) n ) and (iM.C.sIXfiM.pX),,). At 
the molecular level they belong to distinct 
taxons. At the MionCP category, however, 
they fall into the same taxon, (M.C.sI) 
((M.pX)„). 

Interpolating or extrapolating the basic 
set of categories is useful because it lets us 
determine at exactly what level two or 
more computers become architecturally 
identical. 


Examples 

Table 4 shows the molecular formulas 
for a variety of well-known computers, 
while Figures 5-7 display the structures of 
three of these systems. It is interesting to 
compare the present classification of these 
computers with their classification accord¬ 
ing to Skillicom’s scheme. Thus, for ex¬ 
ample, the Illiac IV and the CM-2 Connec¬ 
tion Machine are both class 8 systems 
according to Skillicom’s scheme. In the 
new taxonomy they are quite distinct, not 
only at the MCP level but (as can be easily 
verified) also at the CP, P, and Ultra P 
levels. Even assuming that the Illiac IV has 
a pi rather than an si atom, the two comput¬ 
ers are distinct at the MCP and CP levels. 

In the case of the Cray-1, the C atom in 
the I" molecule represents the instruction 
buffers, and the multiple C component in 
X" represents the multiple scalar, vector, 
and address registers. The Cray-1 does not 
appear to fit very well into Skillicom’s 
scheme. 

With the Cray X-MP, the multiple iM 
component appears in both I" and X" be¬ 
cause main memory comprises four quad¬ 
rants with 32 banks/quadrants. The Cray 
X-MP falls into Skillicom’s class 27. Fi¬ 
nally, the Encore Multimax, which Table 4 
also describes, does not appear to fit into 
Skillicorn’s scheme at all. 

One limitation of the present taxonomy 
is that dataflow architectures can only be 
classified in a somewhat contrived way. 
Consider, for example, the Manchester 
dataflow computer. In this machine in¬ 
structions are prepared for execution by 
passing a token packet from the matching 
unit to the instruction store and selecting 
from the latter the appropriate instruction. 
The hardware complex that does this is the 
I atom. Execution of the instruction in¬ 
volves forming an execution packet com¬ 
prising the instruction and the data tokens 
and having one of the functional units in 
the processing unit process the packet. 
Thus, the individual function units consti¬ 
tute the X atoms. Strictly speaking, the 
matching store in the matching unit is the 
only memory that actually holds operands. 
Thus, one way to characterize the (single 
ring) Manchester machine is by the for¬ 
mula (sM.sI)(sM.sX n ). 

However, given the specified interpreta¬ 
tions of the I and X atoms in our taxonomy, 
this formula is somewhat misleading as a 
taxon for the Manchester machine. 

According to Skillicom, the Manchester 
dataflow machine falls into class 4 (Table 
1). However, I believe this is incorrect, 
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since it recognizes neither the presence of 
an IP (I atoms in our terminology) nor the 
existence of a link between IP and IM. In 
short, neither of the taxonomies appears 
suited to non-von Neumann architectures. 

T he important features of this new 
architectural taxonomic system 
include its hierarchical structure, 
nomenclature, predictive power, and ex¬ 
planatory capabilities. It has been influ¬ 
enced by chemical notations and terms and 
is not only novel in form but also exhibits 
considerable classificatory power. 

Those familiar with Hockney’s classifi¬ 
cation system 9 might see a faint resem¬ 
blance. This is because computers in 
Hockney’s scheme are described by for¬ 
mulas whose development was also in¬ 
spired by chemical notation. The resem¬ 
blance between the two systems ends here, 
however. The rules for construction of for¬ 
mulas and the actual notation are quite dif¬ 
ferent. The TCs and their possible values 
differ considerably. Finally, the hierarchi¬ 
cal organizations and the taxons constitut¬ 
ing the categories in the two taxonomies 
differ sharply. 

As stated early in the article, the pro¬ 
posed taxonomic scheme is not concerned 
with exoarchitectures at all. I have also 
noted its limitation in classifying dataflow 
(and, in general, non-von Neumann) en- 
doarchitectures. It appears that the taxon¬ 
omy presented here cannot be extended 
naturally to cope with such architectural 
domains. Rather, while the same type of 
hierarchical system may remain appropri¬ 


Figure 6. Structure of the Illiac IV. 


ate, the precise nature and definitions of 
the atoms, radicals, and molecules will 
differ significantly. On the basis of this 
idea, I am constructing such a taxonomic 
system for exoarchitectures. ■ 
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STANDARDS 
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Urgency of ethical standards intensifies in computer community 

Michael C. McFarland 
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been active in the IEEE Computer Society for more than 10 years. — F. Buckley 


The past several months, George, an 
electrical engineer working for an aero¬ 
space contractor, has been the quality 
control manager on a project to develop a 
computerized control system for a new 
military aircraft. Early simulations of the 
software for the control system showed 
that, under certain conditions, instabili¬ 
ties would arise that could cause the plane 
to crash. The software was subsequently 
patched to eliminate the specific prob¬ 
lems uncovered by the tests. After the re¬ 
pairs were made, the system passed all of 
the required simulation tests. 

George is convinced, however, that 
these problems were symptomatic of a 
fundamental design flaw that could only 
be eliminated by an extensive redesign of 
the system. Yet, when he brought his con¬ 
cern to his superiors, they assured him 
that the problems had been resolved, as 
shown by the tests. Anyway, to reevalu¬ 
ate and possibly redesign the system 
would introduce delays that would cause 
the company to miss the delivery date 
specified in the contract, and that would 
be very costly. 

Now, there’s a great deal of pressure on 
George to sign nfF5 n"ffie s v steirmtirf al¬ 
low it to be flight tested. It has even been 
hinted that, if he persists in delaying re¬ 
lease of the system, the responsibility 
will be taken away from him and given to 
someone who is more compliant. 

George faces a serious moral dilemma. 
On the one hand, he feels the pressure to 
comply with his superiors’ orders not 
only to protect himself and his family 
from the possible loss of his job but also 
out of loyalty to his company and defer¬ 
ence to the judgment of his superiors. On 
the other hand, as an engineer and par¬ 


ticularly as a quality control manager, he 
feels responsible for the reliability of the 
system and the safety of those using it. In 
his professional judgment, he is not con¬ 
fident the system is safe, so he does not 
feel it would be justified to say it is. 

What makes the situation so difficult 
for George is that he must choose be¬ 
tween conflicting duties: loyalty to self, 
family, employer, and superiors versus 
the obligation to tell the truth and to pro¬ 
tect others from harm. The situation is 
complicated by the fact that, even if 
George chooses not to authorize release 
of the system, it would be done anyway 
without his approval. So, his sacrifice 
would have no practical effect. 

This is a hypothetical case, but not un¬ 
like those many engineers face. 13 In par¬ 
ticular, as society becomes more and 
more dependent on computers in critical 
applications in such areas as defense, 
transportation, medical care, and bank¬ 
ing, computer scientists and engineers 
increasingly find themselves encounter¬ 
ing difficult ethical dilemmas. These in¬ 
volve not only the reliability and safety of 
computer systems but also computer se¬ 
curity and privacy, ownership of pro¬ 
grams and data, the impact of computers 
on the workplace and education, and the 


implications of artificial inte'ligence re¬ 
search. 

How people in the industry handle 
these dilemmas has implications far be¬ 
yond their own success and peace of 
mind; it will affect the welfare of every¬ 
one who depends on computer systems in 
any way. There is, therefore, a growing 
concern about ethical standards among 
computer professionals. Many feel we 
need to work out guidelines on the ethical 
issues facing the profession. Establish¬ 
ing a set of standards that is accepted and 
shared by the whole profession is impor¬ 
tant not only because it can help those fac¬ 
ing difficult ethical decisions to make 
reasonable and fair judgments that serve 
the best interests of everyone involved, 
but also because of the sense of support 
and solidarity such standards can give 
those making the decisions, making it 
easier for them to carry through on those 
decisions with courage and confidence. 

The purpose of this article is not so 
much to propose a set of standards for the 
profession — we still have much to do be¬ 
fore we get to that point — but to provide 
background material on ethical standards 
in general. I will discuss where ethical 
standards come from, how they are ar¬ 
rived at, and how they can be promoted 


March 1990 


77 









and applied. I hope this will help prompt a 
wide-ranging discussion within the pro¬ 
fession in general and the IEEE Com¬ 
puter Society in particular that will result 
in a consensus on a set of standards for the 
profession. 

Two fallacies about ethical knowl¬ 
edge. Ethical standards must be based on 
some apprehension of what is right and 
wrong, of what ought to be done, and of 
what ought not to be done. The first ques¬ 
tion we must consider, therefore, is 
“What is ethical knowledge and where 
does it come from?” 

There are two fallacies about the status 
of ethical knowledge that we must dis¬ 
cuss before we can consider what it is. 

The first and the most prevalent today is 
called ethical relativism. It holds that 
there is no objective, shared ethical truth 
that is knowable by everyone and to 
which everyone can be held accountable. 
In this view, each individual is respon¬ 
sible for his or her own ethical judgments 
and makes them according to his or her 
own perceptions. This is akin to saying, 
“What you feel is right, is right for you.” 
No one else has any justification for criti¬ 
cizing it. 

This view, of course, is consistent with 
the observation that intelligent people of 
good will can hold quite different views 
on important ethical questions. It also 
harmonizes well with the great value our 
culture places on freedom — freedom in 
the sense of noninterference. 

The problem with ethical relativism is 
that, if applied consistently, it makes it 
impossible to ever critique another per¬ 
son’s behavior. If someone thinks it is 
right to sexually abuse children, to rob 
and shoot a taxi driver, or to break into 
private fdes on a computer system, that is 
the individual’s decision. It is not for us to 
decide what is right for that individual. 

When the issue is put this way, it is evi¬ 
dent that, while ethical relativism may be 
attractive in individual cases, especially 
where it seems to spare us painful con¬ 
frontations on ethical issues, it is simply 
not tenable as a fundamental ethical prin¬ 
ciple. If it were taken seriously, there 
could be no ethical standards and thus no 
civilization. 

Another related view that is seemingly 
less extreme but in fact just as dangerous 
is cultural relativism. This states that so¬ 
cieties or cultures can come to a consen¬ 
sus on ethical standards that they can im¬ 
pose on their members but that these stan¬ 
dards are arbitrary. There is no basis for 
saying that one set of standards is supe¬ 
rior to another. 

This view has all the problems of ethi¬ 
cal relativism but, if anything, is worse 
because it operates on a greater scale. If a 
particular society, for example, decides 


that it is right to hold people of another 
race or religion in slavery or to kill them, 
they are justified in doing so. If we accept 
cultural relativism, there is no objective 
basis for opposing such a position. 

This form of relativism, often hidden in 
such cynical phrases as “might makes 
right” and “the winners write history,” 
must also be rejected. It may allow for the 
formation of standards, but there is no 
way of insuring that they have any rela¬ 
tion to good. In particular, there is no 
guarantee of protection for those on the 
fringes of a society. 

In view of the dangers of ethical rela¬ 
tivism, it would be nice if we could show 
that ethical truth is somehow given, as a 
set of rules or principles that we simply 
have to look up somewhere. But, of 
course, we know that there is no com¬ 
monly accepted source that contains the 
answers to all our ethical questions. 

Even within religious or political tradi¬ 
tions that have authoritative statements 
of ethical rules or principles, such as the 
Ten Commandments or the Bill of Rights 
of the US Constitution, it is by no means 
clear or undisputed what the status and 
meaning of these texts are and how they 
are to be applied in all cases. They are im¬ 
portant sources of moral wisdom, au¬ 
thoritative for some, but not the defini¬ 
tive answer to every moral problem. Nor 
is there any philosophical system that of¬ 
fers a clear answer to every dilemma. So, 
how can there be objective ethical truth if 
it is not “out there” waiting for us to find 
it? 

I think an analogy with natural science 
is helpful here. Physics long ago gave up 
the view that the truth about the structure 
and dynamics of the universe is an objec¬ 
tive reality that exists apart from our ask¬ 
ing about it and that can be fully grasped 
through the mechanical application of 
known principles. Rather, what is know- 
able about the physical universe is some¬ 
thing dynamic that takes form through 
our inquiry and experimentation. As 
much as we know about it, we certainly 
have not grasped it all and never will. 

But that does not mean that there is no 
truth that can be known about the physical 
world or that the truth is something com¬ 
pletely arbitrary that we invent. If that 
were true, all science would be in vain, 
and all attempts to understand physical 
phenomena would be useless. 

Yet, scientists go on experimenting 
and constructing theoretical models in 
the belief that these activities can deepen 
their understanding of the phenomena 
they study. Their theories may never be 
complete, but that does not mean that they 
are useless or arbitrary. 

If some theoretical breakthrough 
should reveal that gravity is not an inde¬ 
pendent force but part of a larger scheme. 


everything that past theories of gravity 
have taught us would not be invalidated. 
The planets would still move as they al¬ 
ways have. It would not be that our previ¬ 
ous theories were false, only that they did 
not give the full picture. 

In the same way, ethical knowledge is a 
dynamic reality, neither totally within 
our grasp nor totally beyond it. Ethics has 
its own discipline and its own methodol¬ 
ogy, just as the physical sciences do. Ethi¬ 
cal knowledge emerges from experience 
and reason, from action, and from reflec¬ 
tion on that action. I 

While they are still provisional and pe¬ 
riodically challenged, the principles we 
have built up over thousands of years 
have taught us a great deal about how to 
apprehend and realize the human good. 
Even if they are someday superseded be¬ 
cause we come to a deeper understanding 
of ethical truth, they will not cease to be 
useful. Therefore, it is worth learning 
how to apply them. 

Metaethical principles. We do not 

have a methodology that is precise 
enough to settle all ethical disputes, but 
we do have ways of distinguishing sound 
ethical arguments from fallacious ones 
and deciding on issues where there is a 
clear choice between what is right and 
what is wrong. 

There are four conditions that any ethi¬ 
cal argument must meet to be valid: 


(1) It must be consistent with the facts. 

(2) It must be reasonable and logically 
consistent. 

(3) It must be based on sound prin¬ 
ciples and uphold the highest good. 

(4) It mus t be uniy grsafeafete. That is, 
if an argument asserts that action X is jus¬ 
tifiable in situation Y, then it must also as¬ 
sert that V is justifiable in every sit uation 
Z that dods'not differ from Kin any way 


The first two conditions are obvious 
enough, but nevertheless must be empha¬ 
sized because many ethical arguments 
fail precisely because they do not respect 
the facts or do not hold together logically. 
The third condition requires that we be 
able to identify and prioritize various 
human goods and values. In general, this 
is a very difficult and controverted task, 
about which I will have more to say later. 

Nonetheless, there are many cases 
where the priority is clear. For example, if 
someone injects a destructive virus into a 
computer program because he feels it is 
more important to show his technical ex¬ 
pertise and impress his friends than to re¬ 
spect the needs of those who will lose 
valuable time and data because of the vi¬ 
rus, we can say with some assurance that 
that is not a valid justification. 
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The fourth condition provides the most 
significant and powerful test for ethical 
arguments. First of all, it insures that ethi¬ 
cal standards are applied fairly. I cannot 
assert that there is one rule for me and an¬ 
other rule for everyone else or that one set 
of standards applies to one group and a 
different set to another group that only 
incidentally differs from the first. For ex¬ 
ample, I cannot claim that I am justified in 
copying commercial, copyrighted soft¬ 
ware without authorization unless I am 
willing to accept the implications of ev¬ 
eryone copying software without paying 
— which would mean either outra¬ 
geously overpriced software or the end of 
commercial software altogether. 

Similarly, I cannot claim that it is right 
for me to misrepresent products or break 
contracts when they are not to my advan¬ 
tage unless I am willing to accept others 
lying to me or breaking contracts that 
give me an advantage over them. This 
principle always forces us to ask the ques¬ 
tion, “How would I feel if that were done 

The fourth condition also provides us 
with a powerful means of testing the va¬ 
lidity and applicability of proposed ethi¬ 
cal principles or rules of thumb by testing 
them on a wide range of cases and analo¬ 
gies until we find their limits or see them 
fall apart. For example, out of concern for 
the protection of personal information in 
a large database of credit records, we 
might propose the rule: “It is wrong to al¬ 
low any use of personal information in a 
database without the subject’s consent.” 
But then we would have to test the univer- 
salizability of this rule by asking whether 
there are ever situations where we should 
allow the use of personal information, 
whether in a database or not, without the 
subject’s consent. Of course there are, for 
instance in helping to track a dangerous 
criminal or in investigating cases of child 
abuse. Therefore, the rule is not univer- 
salizable as it is, and we must either reject 
the rule or, more likely, modify it to allow 
certain exceptions, such as matters of 
public safety. But trying to generalize the 
new version of the rule might show the 
need to define more clearly which matters 
of public safety are serious enough to jus¬ 
tify the release of public information, 
who is to decide, and so on. Much ethical 
argument involves the testing and refin¬ 
ing of rules by applying them to analo- 


Ethical principles. The methodology 
sketched in the previous section gives us 
a way of testing and applying ethical prin¬ 
ciples, but it does not tell us what those 
principles are. In this section, I will con¬ 
sider some of the principles that have 
commonly been found to be important. 

The principle of utilitaria nism s tates 


that, in any given situation, that action is 
right which produces the greatest net 
good, that is, the greatest preponderance 
of good over evil. This assumes that all 
goods and evils can be quantified in some 
way and compared on the same scale. 

Utilitarianism is pr obably the ethical 
principle engineers are most comfortable 
with. It is the underlying basis for cost- 
'"benetit analysis, for example, where all 
of the consequences of competing strate¬ 
gies are given dollar values, and the strat¬ 
egy with the highest net gain is chosen. 

Utilitarianism does have many attrac¬ 
tive features. Surely, if we have any ethi¬ 
cal obligation at all, it is to do good and 
avoid evil. Utilitarianism takes that fun¬ 
damental truth and tries to build a precise 
calculus around it. Once a method of 
quantifying goods and evils has been cho¬ 
sen, the system gives definite answers to 
ethical questions, which is very appeal¬ 
ing. 

The most d ifficult ethical cho ices are 
those that ^involve cho asTnp between 
competing goods or the acceptance of 
'certain evils to avoid others. Utilitarian¬ 
ism offers a definite and seemingly unbi¬ 
ased way of making those choices. 

Nevertheless, few ethicists accep t 
ut ilitarianism as totally adequate_ in-it- 
selU-’Thgre are a number of reasons for 
'this. First, utilitarianism is not as obje c¬ 
t ive as it might a ppear- Any particular ' 
utilitarian calculus contains hidden value 
judgments, especially in the way the con¬ 
sequences of actions are quantified. For 
example, how much is a human life 
worth? $100,000? $1,000,000? $1.98? 
Who decides? 

The method we use for assigning value 
to human lives embodies some very im¬ 
portant judgments about the relative 
worth of different human beings. If, for 
instance, we decide to value human 
beings based on their potential economic 
productivity over their lifetimes, as some 
have proposed, we are saying that the el¬ 
derly and those who are severely handi¬ 
capped are worth less and deserve less 
protection and support than others. That 
conclusion is highly debatable, to say the 
least, and can lead to severe abuses. Of 
course, we must make judgments about 
the relative importance of competing val¬ 
ues; that is what ethics is all about. But 
these decisions must be acknowledged 
for what they are and worked out openly, 
not hidden in some supposedly “objec¬ 
tive” system. 

The second problem with utilitarian¬ 
ism is that, in its pure form, i t says no thing 
aboutJtSHUjg nefits^ te-tqbe'di^ributed. 
Therefore, it does nothi ng tol>romote 
faimess-or justice. FoFexaffiptertrcost- 
^Benefit analysis might indicate that it is 
most beneficial overall to place a coal- 
fired power plant for a major city in a rural 


area, next to an Indian reservation. There, 
it would be closer to the sources of coal 
and would inconvenience far fewer 
people than it would were it built in a 
more urban or suburban location. The 
impact of the plant on the Indians — the 
strip mining and the pollution that would 
go with it — would be far more severe 
than it would be on a more urban or subur¬ 
ban population since the Indians depend 
much more on the land and nature in gen¬ 
eral for their economic and spiritual life. 
But since there are so few of the Indians, 
the benefits outweigh the costs. 

The problem, of course, is that this so- 
l ution is extre mely unfair. AlmosrtafFof ' 
the benefits of the plant go to a majority 
urban population that already possesses a 
disproportionate amount of wealth and 
power, while those who are already im¬ 
poverished and discriminated against are 
forced to bear most of the costs. 

The third problem is that, even if utili¬ 
tarianism were acceptable in theory , it 


could in practice never adequately ac- 



might seem in a particular case that tell¬ 
ing a lie would have very little in the way 
of negative consequences and might 
bring great benefits. If lying were al¬ 
lowed in every case where it seemed 
beneficial, however, it would seriously 
weaken the foundation of trust that soci¬ 
ety needs to function. It would also 
weaken the integrity of the one who prac¬ 
tices deceit. 

Consequences such as these are diffi¬ 
cult to foresee and impossible to quan¬ 
tify. For these and other reasons, most 
ethicists feel that utilitarianism in itself is 
not an adequate basis for ethics. At the 
very least, there must be some principle 
that recognizes an obligation to justice in 
the distribution of benefits and burdens. 

Furthermore, it is generally held that 
there are some tv nes o f-ac tions that ar e 'j 
Wongin themselves, so th at-t.here-is-an 
''obligation to avoid them. These include 
^ killing or harming innocent human 
beings, lying, and stealing. Some would 
argue that these are rules of thumb that 
can be derived from a consideration of the 
long-term consequences of the actions in 
question, while others take them to be 
fundamental obligations in themselves. 

In our culture, these obligations are 
most often formulated in the language of 
rights. Fvery h uman being is acknowl- 
edged to possess ce r tain righ ts — to life 
UncTtEe meansTnecessary to sustain it, to 
freedom, to respect, to self-realization, 
and so on. 

/ T he ex istence of these rights creates 
I obligations in others not to interfere with 
tUemTHowever these obligations are ac- 
-Counted for, in practice there is a great 
deal of agreement about their content. 
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The real problems occur when these obli¬ 
gations come into conflict, for example 
when the only way someone can protect 
the life of another is by lying, or when the 
exercise of one person’s freedom inter¬ 
feres with the freedom and self-realiza¬ 
tion of others. 

Often such conflicts are settled when, 
through careful reflection on experience 
and on the relative importance of the val¬ 
ues at stake, people formulate norms or 
guidelines that minimize or avoid the 
conflict and distribute the burdens as 
fairly as possible. These norms often 
emerge through a long process of argu¬ 
ment, testing, and revision, but eventu¬ 
ally, as they prove to be sound and work¬ 
able, they come to be widely accepted as 
binding on those subject to them. 

This is the case, for example, with pro- 
. fessional norms, such as those that define 
the obligations doctors have toward their 
patients and the obligations lawyers have 
toward their clients and the legal system. 

Ethics as social activity. Returning to 
George’s ethical dilemma, it is clear 
enough that, if a technical analysis does 
indeed show that the control system 
poses a significant risk to the lives of pi¬ 
lots and others and that the risk is avoid¬ 
able, the company has an obligation to re¬ 
design the system. But that does not solve 
George’s problem. Whatever choice he 
makes will involve some significant evil. 

The problem is that he is trying to act 
ethically in an unethical environment. 
This does not absolve him of the responsi¬ 
bility of doing what is right as best he can, 
but it does mean that whatever choice he 
makes will not be satisfactory. It also 
means that he will suffer for things that 
are not his fault. 

The social structures George operates 
in have failed him by not giving him the 


To go further 

To learn more on this subject or 
to get involved in this or similar is¬ 
sues, contact 

• Ralph Preiss, Chair, IEEE 
Computer Society Committee on 
Public Policy, 12 Colburn Dr., 
Poughkeepsie, NY 12603. 

• Computer Professionals for 
Social Responsibility, PO Box 
717, Palo Alto, CA 94301. 


support he needs. There are a number of 
reasons for this: 

• There are no clear guidelines to de¬ 
fine the responsibilities of George and his 
coworkers and superiors with regard to 
the safety of the system. His superiors can 
argue that as long as the system has 
passed the required tests, they have ful¬ 
filled their responsibilities. 

• There is no incentive for George or 
his company to behave ethically, that is, 
to make every effort to ensure the safety 
of the system. In fact, there are strong dis¬ 
incentives in the way the contract is struc¬ 
tured. 

• There is no structure or procedure that 
allows George to make his concerns 
known. If his superiors refuse to consider 
his concerns, there is nowhere he can go 
without appearing disloyal to his com¬ 
pany. 

• The burden of the decision is unfairly 
placed on George. He will pay a high 
price no matter what he does, while it is 
really the responsibility of the whole 
company to guarantee the safety of the 
system. 

In this case, the problem is not primar¬ 
ily that individuals are acting unethi¬ 
cally, although there may be some of that. 
The main difficulty is that the social 
structures themselves are not adequate to 
deal with the problem. And, when that is 
the case, an individual acting alone can¬ 
not hope to correct it. 

Even if George, at great personal risk, 
should blow the whistle by taking his con¬ 
cerns outside the company, he might well 
be discredited so that his efforts will have 
no effect. And, he will certainly lose his 
job. In addition, there is a possibility that 
he is wrong about the safety of the system, 
in which case he would be hurting himself 
and his company for no reason. 

Although this case is hypothetical, it is 
not implausible. In fact, we as computer 
professionals face many difficult ethical 
problems, and these problems are inextri¬ 
cably tied to the social systems in which 
we function. The problem of copying 
software has to do with the proper func¬ 
tioning of the free market, for example. 
The privacy issue involves massive data¬ 
bases and the organizations that use 
them, such as the FBI, the IRS, and credit 
card companies. There are many other 
examples. 

Individual action will not solve any of 
these problems. Social problems require 
social solutions. Computer professionals 
need to act together to make sure the 
norms and structures that support ethical 
activity are in place. 

Some of the^thingsneeded are 

(1) Professional/norms. General ex¬ 


hortations to be good and responsible are 
not sufficient. There must be specific 
definitions of the rights and duties of 
computer professionals with respect to 
the ownership of software and data, secu¬ 
rity, safety, reliability, and so on. 

(2) A forum for di scussing ethical 
problems, t hose involvedlfrethical con¬ 
flicts or facing ethical dilemmas should 
have a place where they can discuss the 
issues and receive the wisdom and sup¬ 
port of their peers. It would also be very 
helpful if there were an independent body 
that could investigate the claims of those 
like George who perceive serious threats 
to the public welfare. 

(3) A way of adjudicating conflicts. 
There must be some way of making mem¬ 
bers of the profession accountable. The 
norms referred to in (1) will work only if 
most members of the profession accept 
them voluntarily, but there also has to be a 
system for protecting the members of the 
profession and others from those who 
would try to gain an unfair advantage by 
ignoring the norms. This system must be 
open and fair and must observe the can¬ 
ons of due process. It must be possible to 
bring some sanctions against those who 
violate the norms in an especially de¬ 
structive or scandalous way. 

(4) SupB orufor-members who are per¬ 
secuted for ethical actions. The profes- 
siorrstfould stand up for members who are 
willing to take stands on ethical issues 
where this brings them into conflict with 
their organizations. This would be easier, 
of course, if the kind of structure sug¬ 
gested in (2) existed; it could help judge 
and mediate such conflicts. 

The IEEE Computer Society is a pro¬ 
fessional organization that represents 
many computer scientists and engineers. 
As such, it is an obvious vehicle for the 
kind of organized activity suggested in 
points (1) through (4) above. In fact, there 
has been some activity in these areas, al¬ 
though to date it has been rather limited. 

IEEE Spectrum has an outstanding rec¬ 
ord on investigating ethical issues, al¬ 
though for the most part it has avoided 
taking stands on these issues and has not 
been involved in the formulation of 
norms. The IEEE has a code of ethics, but 
the code is too general to give much guid¬ 
ance on the specific issues facing com¬ 
puter professionals. 

Last year, there was a strong effort 
within the Computer Society Committee 
on Public Policy to produce a position pa¬ 
per on computer viruses (see Computer, 
July 1989, pp. 83-84) that included some 
norms. This proposed statement seerhs to 
have died, however, when it reached thp 
society's Board of Governors for adop- 

The IEEE does have procedures for 
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dealing with accusations of unethical 
conduct, although these are little used 
and weak when it comes to providing due 
process. 

There are a number of reasons the IEEE 
and the Computer Society have not done 
more. Engineers are generally uncom¬ 
fortable with ethical issues. They feel 
those issues are outside their competency 
sphere and are not as well-defined or as 
susceptible to rigorous analysis as purely 
technical problems. 

Furthermore, becoming involved with 
ethical problems is risky. The stakes are 
often very high and feelings run deep, so 
these issues can lead to confrontations 
and divisions. I also suspect that the IEEE 
has never quite figured out if it represents 
management or the working engineer, so 
it would rather not get involved in poten¬ 
tial conflicts between the two. 

Whatever the reasons for the reluc¬ 
tance to get involved in ethical issues, we 
can no longer afford it. Computer profes¬ 
sionals must find a way to take common 
action on the issues facing the profession 
if they are to fulfill their responsibilities 
to society and to themselves. If they do 
not act on their own, they will find them¬ 
selves subject to legislation made by 
people who do not really understand the 
issues involved. 

Let us hope that the IEEE can facilitate 
the kind of organized action that is 
needed in the profession. If not, then an¬ 
other context must be found. 
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Minds over _ 

^ Matter — 


Program Coordinator-Computer Security 

As head of the DOE Center for Computer Security and 
Program Coordinator for our DOE Classified Computer 
Security R&D Program, you will work with Laboratory and 
DOE management to develop/implement an innovative 
applied R&D program to support the security needs of the 
DOE community. Will serve as program liaison between the 
Laboratory and DOE Office of Safeguards and Security 
(OSS) while representing each with other government 
agencies and national laboratories. Specific areas of 
programmatic emphasis in the applied R&D program are 
software verification, network security, operating system 
security, application of expert system technology to com¬ 
puter security problems, applications of automated learning 
to detect intrusions into computer systems, and database 
security. 

This position requires demonstrated accomplishment in 
computer science or computer security as evidenced by 
substantive technical publications or prior experience in 
managing a successful applied R&D program in computer- 
related area. The ability to communicate with all levels of 
management is essential. Successful program management 
experience desirable. Master’s degree in Computer Science 
or equivalent combination of education and relevant 
experience is required. 

As a leading R&D institution, we provide a challenging work 
environment and an attractive salary/benefits package to 
match. To formally apply for this position, you must 
reference Job Number 90926 on your resume. Please send 
resume to Portia Blackman (MS P280), Personnel Services 
Division 90926-B, Los Alamos National Laboratory, Los 
Alamos, NM 87545. 

Affirmative Action/Equal Opportunity Employer. Must be 
able to obtain a Department of Energy Security Clearance. 


University of California 

L®@ 


March 1990 












UPDATE 


Contributions to Update are welcome. Send news of public policy or professional issues and of industrial or university research to Steve Wilcox, 10662 Los Vaqueros Circle, PO Box 
3014, Los Alamitos, CA 90720-1264, or to Editor-in-Chief Bruce D. Shriver, Vice President for Research, University of Southwestern Louisiana, Drawer 42370, Lafayette, LA, 70504. 


Ruling clarifies US software-import rules 

Galen Gruman, Staff Editor, IEEE Software 


The Singapore government subsidized 
a CASE system imported into the US and 
could be forced to pay duties on future 
imports of the product, the US Commerce 
Dept, said in a preliminary ruling that 
clarifies the department’s software- 
import policy. 

The ruling issued Jan. 9 categorizes 
packaged software as merchandise rather 
than intellectual property. “The determi¬ 
nation is significant because it does indi¬ 
cate that we will consider software to be 
subject to our countervailing duty law,” 
said Eric Garfinkel, assistant secretary of 
commerce for import administration. 
Countervailing duties are taxes levied 
against imports that the US believes have 
been unfairly subsidized. 

The Commerce Dept, inquiry began in 
September 1989 after Visible Systems, a 
CASE manufacturer based in Waltham, 
Mass., alleged that Singapore’s National 
Computer Board had subsidized the 
Picture-Oriented Software Engineering 
analysis and design tool, thus artificially 
lowering its price in the US. The National 
Computer Board’s Information Technol¬ 
ogy Institute developed POSE and then 
contracted with the Singaporean firm 
Computer Systems Advisors to market it 
internationally as part of an effort to pro¬ 
mote local software firms. POSE is mar¬ 
keted in the US by Computer Systems 
Advisors Research, a subsidiary of CSA. 

The Commerce Dept, examined 18 ar¬ 
eas of potentially unfair subsidies but 
stated in its preliminary ruling that CSA 
received only one type of subsidy: The 
royalty rate CSA agreed to pay to the In- 
formatiqn Technology Institute was 
15.25 percent less than the institute’s de¬ 
velopment and expected maintainance 
costs for POSE. 

“We preliminarily conclude .. . that no 
sound commercial basis existed for [the 
institute] to enter into the agreement with 
CSA,” the Commerce Dept, said in its rul¬ 
ing. However, the department acknowl¬ 
edged that its ruling was based on incom¬ 
plete information and could be reversed. 
A final decision is expected in late March. 

Based on its findings, the Commerce 


Dept, ordered that CSA pay a bond of 
$42,892 to continue importing POSE un¬ 
til a final decision is reached. The bond 
amount matches the department’s esti¬ 
mate of the subsidy for copies of POSE 
that have already been imported. The de¬ 
partment will decide a countervailing 
duty for subsequent imports in its final 
decision, unless it reverses its prelimi¬ 
nary ruling. 

The Singapore government will pro¬ 
vide to the best of its ability the informa¬ 
tion needed by the Commerce Dept., said 
Cecelia Khoo, first secretary for econom¬ 
ics in Singapore’s embassy in Washing¬ 
ton, DC. The Commerce Dept, is now 
seeking details on bids by CSA and other 
firms for the rights to POSE to see what 
type of return the Information Technol¬ 
ogy Institute sought. 

The institute rejected an initial bid 
from CSA because the royalties were too 
low, Khoo said. She did not know the de¬ 
tails of the second, accepted bid, but she 
said the institute’s “intention is to get 
more back than invested.” 

The Commerce Dept, said it found no 
evidence of Visible Systems’ other alle¬ 
gations that the Singapore government 
gave CSA a $ 15-million grant and paid 
the salary of a CSA employee. The depart¬ 
ment also investigated possible -subsidies 
involving tax breaks and investment al¬ 
lowances available from the Singapore 


government to promote the development 
of Singaporean technology firms, but it 
ruled that CSA used none of these. 

In its decision, the department rea¬ 
soned that packaged software is compa¬ 
rable to books or sound recordings, which 
are treated as merchandise. That is, al¬ 
though based on intellectual property, 
packaged software represents a fixed in¬ 
stantiation of an idea packaged, invento¬ 
ried, and sold like other merchandise. 

This denied Singapore’s claim that the 
imported disks were not subject to duties 
because they were not the final, packaged 
software. “The master disk used for the 
production of the final prepackaged mer¬ 
chandise is imported, in fact, from Sin¬ 
gapore,” the ruling said. 

However, software transmitted elec¬ 
tronically for eventual distribution as 
packaged software would not be consid¬ 
ered an import, the Commerce Dept.’s 
Garfinkel said. The same is true for books 
and other intellectual property. Because 
there is no way to monitor incoming 
transmissions and decide which may re¬ 
sult in products, the US exempts them 
from customs duties — “They’re not 
reachable,” he said. 

[The March 1990 issue of IEEE Soft¬ 
ware contains a longer version of this 
story, including a closer examination of 
the Commerce Dept.’s software-import 
policy as revealed by the ruling. — Ed] 


Computer science pioneer Perlis dead at 67 


Alan J. Perlis, a pioneer in compiler 
and assembler development and in 
language design, died February 7 of a 
heart attack. 

Perlis founded the graduate com¬ 
puter science department at the Carne¬ 
gie Institute of Technology, now Car¬ 
negie Mellon University. He had been 
a faculty member at Purdue Univer¬ 
sity from 1950 to 1956 and at Carnegie 


Mellon from 1956 to 1971. He then 
moved to Yale University, where he 
played a leading role in developing 
that college’s computer science cur¬ 
riculum and department. 

Perlis received the Turing Award in 
1966 and was president of the Asso¬ 
ciation for Computing Machinery and 
editor-in-chief of Communications of 
the ACM. 
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The national agenda: 

A special report from the Computer Science and Technology Board 


J. F. Traub, Columbia University 

From its inception three years ago, the 
Computer Science and Technology 
Board recognized that competitiveness 
of the US computer industry is paramount 
to the country’s economic well-being and 
national security. Nearly half of the 
board’s current and past projects, sum¬ 
marized below, concern some aspect of 
US competitiveness. 

CSTB is a board of the National Re¬ 
search Council, the operating arm of the 
National Academies of Science and Engi¬ 
neering. The board consists of 20 indi¬ 
viduals, half from corporations and half 
from universities. Roughly half the 
board’s support is from industry and half 
from the federal government. 

The board seeks to identify the major 
national issues relating to computers. It 
does this in consultation with key govern¬ 
ment agencies and industry leaders. 

When an issue is identified it becomes the 
subject of a study, forum, symposium, or 
workshop. 

The project reports mentioned below 
are available by writing to the Computer 
Science and Technology Board, National 
Research Council, 2101 Constitution 
Avenue, NW, Washington, DC 20418. 

CSTB projects. Five of CSTB’s cur¬ 
rent and past projects, those listed first 
below, are of particular relevance to com¬ 
petitiveness. 

Keeping the US computer industry 
competitive: Defining the agenda. A May 
1989 colloquium addressed the question 
of whether the US could retain its preem¬ 
inence in computer-related markets if 
leadership in certain segments devolves 
to other countries. The colloquium, 
chaired by Samuel H. Fuller of Digital 
Equipment Corporation, brought top ex¬ 
ecutives from the US computer industry 
and leading university researchers to¬ 
gether with senior government policy¬ 
makers. 

Colloquium attendees reached a strong 
consensus: Ensuring that the nation has a 
vigorous computer sector at the begin¬ 
ning of the next century requires strategic 
commitment, leadership, and collective 
will that cannot be attained with a “busi¬ 
ness as usual” approach by industry or 
government. 

CSTB plans to examine several of the 
issues raised at the colloquium in detail. 

A report is forthcoming. 

The national challenge in computer 
science and technology. This 1988 re¬ 


port, prepared by CSTB under the leader¬ 
ship of Michael L. Dertouzos of Massa¬ 
chusetts Institute of Technology, dis¬ 
cusses why the US innovation engine 
worked so well in the past and why it may 
not run so well in the future. It highlights 
the scientific, engineering, and techno¬ 
logical thrusts most likely to influence 
the evolution of computing in the next 
decade and makes two broad recommen¬ 
dations: 

• Improve and expand information net¬ 
working. 

• Support fundamental research in 
computer science and technology. 

Toward a national research network. 
This study was requested by the Federal 
Coordinating Council for Science, Engi¬ 
neering, and Technology and chaired by 
Leonard Kleinrock of the University of 
California at Los Angeles. The report, is¬ 
sued in 1988, concludes that the US 
would benefit significantly from the 
creation of a national research network. 
Such a network could dramatically im¬ 
prove the productivity and quality of out¬ 
put of the US research community. Cop¬ 
ies of the report are available. 

Global trends in computer technology 
and their impact on control. This study 
was requested by the State Department 
and chaired by Seymour E. Goodman of 
the University of Arizona. It recom¬ 
mends that certain computer products, 
such as personal computers, be treated as 
commodities. At the same time, the US 
should focus export control efforts on 
technologies such as advanced chip fab¬ 
rication facilities, supercomputers, and 
computer-aided design systems. Copies 
of a report are available. 

Intellectual property issues in soft¬ 
ware. CSTB’s first Annual Strategic Fo¬ 
rum examined intellectual property is¬ 
sues in software. It was held November 
30-December 1, 1989, following a Sep¬ 
tember 1989 advance workshop; both 
were chaired by Lewis Branscomb of 
Harvard University. 

The lack of good intellectual property 
protection for software is widely viewed 
as a serious disincentive to the creation of 
new software. Participants said the forum 
permitted a valuable exchange of infor¬ 
mation and views between intellectual 
property attorneys and software develop¬ 
ers. A report is being prepared. 

Scaling up: A research agenda for soft¬ 
ware engineering. Participants in a Feb¬ 
ruary 1989 workshop agreed that re¬ 


searcher-practitioner interactions are 
particularly important in complex soft¬ 
ware systems research. The workshop, 
chaired by Victor A. Vyssotsky of DEC, 
reached consensus on both short- and 
long-term directions for change in soft¬ 
ware engineering research. Copies of a 
report are available. 

Supercomputer survey. A supercom¬ 
puter panel, chaired by David Kuck of the 
University of Illinois, surveyed individu¬ 
als who design, manage, and use super¬ 
computers. Responses have been tabu¬ 
lated and analyzed. Copies of a summary 
analysis are available. 

Review of NASA computer science re¬ 
search program. This study, requested 
by the National Aeronautics and Space 
Administration and chaired by Irving 
Wladawsky-Berger of IBM, recom¬ 
mended increased emphasis in the area of 
software engineering. Copies of a report 
are available. 

Scope and direction for computer sci¬ 
ence and engineering. A new CSTB 
study, chaired by Juris Hartmanis of Cor¬ 
nell University, seeks to characterize 
how to best organize and conduct com¬ 
puter research and teaching. Among the 
questions to be addressed are 

• What is the intellectual content of the 
field, and how is it evolving? 

■ What is the structure of the field? 

• How is the university environment 
for the field evolving? 

• Where is the leadership in the field? 

Computer security. This study, re¬ 
quested by the Defense Advanced Re¬ 
search Projects Agency and chaired by 
David Clark of MIT, is currently under¬ 
way. Initial phases will describe and cate¬ 
gorize information technology risks and 
options for abating them. Building on this 
technical foundation, subsequent phases 
will evaluate the adequacy of existing 
policy for responding to these risks and 
develop recommendations for improving 
policy and directing research. 

Computational aspects of mapping the 
human genome. An April 1990 work¬ 
shop, leading to proceedings and recom¬ 
mendations, will build on planning di¬ 
rected by Eric Lander of the Whitehead 
Institute and Robert Langridge of the 
University of California at San Fran¬ 
cisco. Its goal will be to identify the po¬ 
tential contributions of computer science 
as seen by leading experts in computer 
and biological sciences. 
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Cooperative activities. CSTB is 
working with other academy groups on 
the following projects. 

Human resource supply and demand. 
The National Research Council’s Office 
of Science and Engineering Personnel 
plans to look at human resource issues in a 
number of scientific disciplines. OSEP 
has requested CSTB cooperation in its 
study of computer science and engineer¬ 
ing. The proposed study will identify the 
inadequacies of the human resource base 
and determine how to supplement that 
base. It will provide a much-needed com¬ 
prehensive picture of supply and demand. 

Japanese-to-English machine trans¬ 
lation. Concerned that the US is lagging 
on Japanese-to-English machine trans¬ 
lation, the Department of Commerce has 
asked the academy’s Office of Japan Af¬ 
fairs, in cooperation with CSTB, to assess 
this area. A December 1989 workshop 
brought together private-sector research¬ 


ers and government officials to review 
technical status and market trends in ma¬ 
chine-translation technology in the US 
and Japan. A report is being prepared. 

Supercomputer symposium. In coop¬ 
eration with the Academy Industry Pro¬ 
gram, CSTB sponsored a supercomputer 
symposium in September 1988. The sym¬ 
posium on the development and use of 
supercomputers in the US focused on 
prospects for industrial applications and 
attracted many high-level industry, uni¬ 
versity, and government leaders. Copies 
of a report are available. 

Export controls study. The Committee 
on Science, Engineering, and Public Pol¬ 
icy has been commissioned to develop a 
methodology for interpreting export con¬ 
trol regulations of the Coordinating 
Committee for Multilateral Export Con¬ 
trol. CSTB has been asked to assist with 
the treatment of computer-related tech¬ 
nologies. 


Bug disrupts AT&T service 


Galen Gruman, Staff Editor, 

IEEE Software 

An error in a telephone switching sys¬ 
tem’s software caused AT&T switching 
nodes to incorrectly believe they were 
overloaded, disrupting US long-distance 
service for about nine hours January 15. 
About half the long-distance calls placed 
that day were not connected, AT&T esti¬ 
mated. 

The error occurred in a new version of 
the switching system, called Signaling 
System 7, that was installed in some of the 
AT&T network’s 114 switching nodes. 
Instead of determining alternative paths 
for calls in cases of congestion, the new 2- 
million-line software responded by pass¬ 


News briefs 

Congressional Fellowship deadline 
nears. March 30, 1990 is the postmark 
deadline for applications to the IEEE- 
USA’s 18th annual competition for con¬ 
gressional fellowships. IEEE-USA se¬ 
lects engineers for one-year internships 
on the personal staffs of individual sena¬ 
tors or representatives as well as on the 
professional staffs of congressional com¬ 
mittees. 

Two fellowships are planned for 1991. 
Further information and application 
forms are available from W. Thomas 
Suttle, Congressional Fellows Program, 
Institute of Electrical and Electronics 
Engineers, 1111 19th St. NW, Suite 608, 


ing congestion alarms to other nodes, 
which reacted as if they too were con¬ 
gested. To restore full service, AT&T re¬ 
verted to Version 6 of the switching soft- 

Although AT&T has developed a 
model to determine software reliability, 
it did not apply that model to the failed 
switching software because the model is 
still being validated, said Gary Morgen- 
stem, an AT&T spokesman. 

The system had undergone extensive 
testing, including testing with live data. 
The error that occurred had “an extremely 
low probability of occurrence,” Morgen- 
stem said. “We can’t test all possible con¬ 
ditions,” he added, but defended AT&T’s 
record by saying, “This is the first gaffe in 


Washington, DC 20036-3690, phone 
(202) 785-0017. 


AT&T builds digital optical proces¬ 
sor. AT&T scientists have demonstrated 
an experimental digital optical processor 
that processes information with light 
rather than electricity. 

Because optics can handle many light 
beams at once, optical processors may be 
able to process more than 1,000 times as 
much information as their electronic 
counterparts. Today, virtually all infor¬ 
mation processors are electronic. 

Although the optical processor demon¬ 


New projects. CSTB continues to con¬ 
sider new projects that meet the board’s 
criterion of a major national issue relat¬ 
ing to computers. Two such projects are 
now under development. 

Computers and education. The serious 
problems facing the country in elemen¬ 
tary and high school education are widely 
known and acknowledged. How can com¬ 
puters make a significant difference? 

Productivity in the service sector. The 
service sector far exceeds the manufac¬ 
turing sector in the nation’s economy. It 
is therefore of particular concern that 
commonly used productivity measures 
show a decline in white-collar productiv¬ 
ity, despite the increasing penetration of 
computers in the service sector. Is the 
problem with how we measure productiv¬ 
ity in a service economy? If so, what 
measures should be used? If productivity 
in the service sector is truly declining, 
what might be done to turn that around? 


a hundred years. We are comfortable in 
terms of the testing [done], but we recog¬ 
nize that quality is a moving target.” 

“AT&T’s problems are a shot across 
the nation’s bow, warning us that small 
problems in complex software systems 
can bring the nation to its knees,” said 
New Jersey Rep. Robert A. Roe in a state¬ 
ment. Roe chairs the US House of Repre¬ 
sentatives’ Committee on Space, Sci¬ 
ence, and Technology. “Government and 
industry must devote more resources to 
the development of software systems that 
are as safe and reliable as they are sophis¬ 
ticated,” he said. 

[The March issue of IEEE Spectrum 
contains a detailed report of the incident. 
— Ed] 


strated operates at only 1 million cycles 
per second, AT&T stated that an optical 
computer operating at several hundred 
million cycles per second is possible in 
the near future. 

The processor's primary components 
include symmetric self-electro-optic ef¬ 
fect devices (S-SEEDs), which are opti¬ 
cal switches with a potential speed of 1 
billion operations per second and a 
switching energy of about 1 picojoule. 
The devices measure 5 microns square 
and contain two mirrors with controllable 
reflectivity to infrared light. There are 32 
S-SEEDs on each of four arrays, and each 
S-SEED can drive two inputs. 
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Computer language TC sponsors conferences, 
other activities 

Boumediene Belkhouche, Chair, Technical Committee on Computer Languages 


Through sponsorship of conferences, a 
newsletter, and other activities, the IEEE 
Computer Society’s Technical Commit¬ 
tee on Computer Languages strives to 
provide a focus and a forum for profes¬ 
sionals with vested interests in computer 
languages. 

These interests extend beyond the con¬ 
fines of traditional programming lan¬ 
guages to cover imperative, functional, 
and logic-based programming languages; 
specification and design languages; ob¬ 
ject-oriented languages; visual and 
graphical languages; and artificial intel¬ 
ligence languages. TCCL seeks to ad¬ 
dress such relevant issues as design, for¬ 
mal definition, implementation, use, 
human factors, and assessment of these 
languages. 

Every year, TCCL sponsors the IEEE 
Computer Society Conference on Ada 
Applications and Environments, the 
Logic Programming Symposium, and the 
International Conference on Computer 
Languages (ICCL). TCCL’s next confer¬ 
ence is ICCL 90, to be held March 12-16 
in New Orleans. The advance program 
appears in the January issues of Com¬ 


puter (pp. 78-79) and Communications of 
the ACM. A tutorial on the functional lan¬ 
guage Haskell and a tutorial on Concur¬ 
rent C will be presented in conjunction 
with ICCL 90. The technical program in¬ 
cludes high-quality papers covering 
theoretical as well as practical language 
issues. 

TCCL publishes a quarterly technical 
newsletter that links committee members 
and provides them with a forum. It covers 
all areas of computer languages. An edi¬ 
tor-in-chief and several associate editors 
oversee the newsletter’s quality and 
timely publication. 

Another TCCL activity is editing spe¬ 
cial issues of Computer Society publica¬ 
tions. For example, the best papers pre¬ 
sented at TCCL-sponsored conferences 
are selected and published in special is¬ 
sues of Computer and IEEE Transactions 
on Software Engineering. 

For more information on TCCL, con¬ 
tact the chair, Boumediene Belkhouche, 
Computer Science Department, Tulane 
University, New Orleans, LA 70118, 
phone (504) 865-5840, e-mail 
bb@cs.tulane.edu. 


Stephen Miller, Sushil Jajodia receive 
Outstanding Contribution Certificates 


The IEEE Computer Society has 
awarded Outstanding Contribution Cer¬ 
tificates to Stephen W. Miller for his 
work toward the establishment and ac¬ 
ceptance of the Mass Storage Reference 
Model and Sushil Jajodia for technical 
and administrative leadership while serv¬ 
ing as chair of the Computer Society’s 
Technical Committee on Data Engineer¬ 
ing. 

The awards were announced at Super¬ 
computing 89 in Reno, Nevada, but inad¬ 
vertently omitted from subsequent cov¬ 
erage in Computer (Jan. 1990, pp. 83-84). 

Miller, who has had a long career at SRI 
International, became interested in mass 
storage systems when he chaired a 
DARPA workshop on advanced memory 


concepts in 1976. While serving on the 
Executive Committee of the Computer 
Society’s Technical Committee for Mass 
Storage Systems, he suggested that the 
TC form a special working group to de¬ 
velop the Mass Storage Reference Model, 
and he served as chair for the group. 

Jajodia is a professor of information 
systems and systems engineering at 
George Mason University in Fairfax, 
Virginia. His research interests include 
information systems security and distrib¬ 
uted databases. A long-time Computer 
Society member and a senior member of 
the IEEE, he has actively supported the 
society’s publications efforts in several 
capacities, in addition to his work on the 
technical committee. 


Technology Transfer to Go 

The latest issue of a computing 
journal arrives and you dread the 
effort it will take to decode the in¬ 
formation it contains. You’ve got 
the opposite problem with the 
mass-market computer maga¬ 
zines: They’re easy to read but not 
very substantive. 

That’s where IEEE Software 
comes in. We combine the advan¬ 
tages of peer review, timely publi¬ 
cation, clear writing, and clean 
design. We put effort into the 
presentation so you don’t have to 
in the reading. Think of us as por¬ 
table technology transfer. 

We’re what a technical magazine 
should be: Practical. Authorita¬ 
tive. Lucid. Direct. 

For subscription information, write IEEE 
Software, 10662 Los Vaqueros Cir., PO Box 
3014, Los Alamitos, CA 90720-1264; call 
(714) 821-8380; or use the reader-service 
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CALL FOR PARTICIPATION 

Visualization ’90 

Sponsored by IEEE Computer Society, Technical Committee on Computer Graphics 
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ME INSTITUTE OF ELECTRICAL 


October 23-26,1990 San Francisco, California 

The conference will explore how visualization is being used to extract knowledge from 
data. The conference is concerned with all aspects of visualization, with a focus on 
interdisciplinary techniques. The conference will allow a dialogue to occur between 
the developers of visualization methods and visualization users across the full spectrum 
of science, engineering and business. 


CONFERENCE 

Co-chairs: 

Bruce Brown 
Oracle 
Gary Laguna 

Lawrence Livermore Nat’l Lab 

PROGRAM COMMITTEE 


Paper Submission (due May 15,1990) 

Original papers for the conference proceedings should be limited to 5000 words. 
Where appropriate, the use of video as part of the paper is strongly encouraged. 
Videos should be submitted for review with papers. Authors considering 
submitting a video should obtain submission information from the video chairs 
prior to submission. Four copies of each paper (and video) should be submitted to 
the papers chair. 

Papers Chair: Video Co-chairs: 

Arie Kaufman Jeff Posdamer Marian Posdamer 

Computer Sci. Dept. JvN NSC Dana Communications 

SUNY at Stonybook 665 College Road East 2 East Broad Street 

Stonybrook, NY 11794-4400 Princeton, NJ 08540 Hopewell, NJ 08525 

(516) 632-7441 (609) 520-2000 (609) 465-9187 


Panel & Tutorial Proposals (due May 1,1990) 

Proposals for panels and 1/2 day tutorials (beginning & advanced) are solicited. 
These should emphasize the application of scientific visualization to problems i 
research, development, demonstration, or business. 

Panels Co-chairs: 

Georges Grinstein R. Daniel Bergeron 

Graphics Res. Lab Dept, of Computer Sci. 

University of Lowell Univ. of New Hampshire 

Lowell, MA 01854 Durham, NH 03824 

(508) 934-3627 (603)862-2677 


Tutorial Chair: 

David Salzman 
JvN NSC 

665 College Road East 
Princeton, NJ 08540 
(609)520-2000 


Interdisciplinary Case Studies (due May 1,1990) 

Proposals examining the interdisciplinary nature of visualization, tools and real time 


applications are especially solicited. Persons interested in submitting a case study 
should contact one of the co-chairs. 

Case Study Co-chairs: 

Paul Hazan Donna Cox Laurin Herr 

Applied Physics Lab. N. Cent. Supercomputer App.Pacific Interface 

John Hopkins Univ. 605 East Springfield 125 West 72nd St. 

Laurel, MN 20707 Champaign, IL 61820 New York, NY 10023 

(301)953-5364 (217)244-0072,2005 (212)877-9159 


Demonstrations (due June 1,1990) 

A portion of the conference will be devoted solely to demonstrations. Research 
organizations and commercial companies interested in presenting should contact the 


co-chairs. 

Demonstration Co-chairs: 

Jerome Cox 

Department of Computer Science 
Washington University, Box 1045 
St. Louis, MO 63130 
(314) 889-6132 


Val Watson 

NASA Ames Research Center 
MS 258-2 

Moffett Field, CA 94035-4000 
(415) 604-6421 


Subsequent Publications 

The program committee will select papers to be updated and appear in a special 
issue of IEEE Computer Graphics and Applications. It is expected that videos will 
be published by the Computer Society. 
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PRODUCT REVIEW 


Editor; Richard Eckhouse, UMASS-Boston, Harbor Campus, Boston, MA 02125, Compmail+, r.eckhouse; Bitnet, eckhouse@umbsky; CompuServe, 70516,556 


Life with Ada 

T.L. (Frank) Pappas, AWEB Consulting 


Getting involved with Ada can be frus¬ 
trating or enjoyable, depending on 
whether you have the tools and informa¬ 
tion to help you get started. In this issue, 
I'm going to look at a few tools, a com¬ 
piler, and some sources of information. 

While my perspective in this issue fa¬ 
vors smaller companies and consultants 
because I’m particularly sensitive to cost 
and productivity tradeoffs, it is equally 
valid for large companies with their 
larger operating budgets. I hope many of 
our readers will find it useful. 

Meridian Ada 
comes of age 

Meridian has vastly improved the 
AdaVantage Ada compilation system 
from version 2.1 (reviewed in the Sep¬ 
tember 1988 issue, pp. 95-96) to version 
4.0.1 found many things wrong with the 
earlier version that made it almost unus¬ 
able, so I gave it a pretty negative re¬ 
view. Meridian has corrected most of 
what I disliked about the product. I really 
like version 4.0 and feel that AdaVan¬ 
tage is now a production-quality com¬ 
piler. 

AdaVantage requires DOS 2.1 or later. 
An IBM PC XT clone is sufficient if you 
only want to run and compile real-mode 
programs. You’ll need an AT/286 or AT/ 
386 if you want to compile or execute 
extended-mode programs. The compiler 
takes about 2 Mbytes of disk space. 

The professional development system 
costs $1,995. It includes a utilities pack¬ 
age, a DOS environment library, a de¬ 
bugger, an optimizer, and a development 
environment. 

AdaVantage update. Since I re¬ 
viewed version 2.1, I’ll first describe 
how AdaVantage has improved, using a 
few broad categories to describe the 
changes. Later I’ll describe the new fea- 

Be careful when you read this section, 
since I will be discussing problems with 
version 2.1 and how they have been re¬ 


solved in version 4.0. If you don’t read 
this section carefully, you will get the 
false impression that I don’t like version 
4.0, and that couldn’t be further from the 
truth. 

Code generation. AdaVantage now 
supports real and extended (286) modes. 
Extended mode works in two ways. You 
can compile a real-mode program while 
keeping the compiler in real mode. If the 
program is too large to compile in real 
mode with AdaVantage, you can place 
the compiler in extended mode and still 
generate your real-mode program. If 
your program must run in extended mode 
rather than real mode, you can specify 
that to the linker. This is the only part of 
AdaVantage that I had any difficulty 
with, so let’s get it over with first. 

The problem with extended mode is 
that every manufacturer’s AT/286 or AT/ 
386 is different. Typically, a compiler 
vendor uses a DOS extender to create ex¬ 
tended-mode programs because it 
doesn’t make sense for the vendor to test 
every possible clone. This means that 
vendors depend heavily on the DOS ex¬ 
tenders they use. Meridian has just added 
support for extended-mode programs to 
AdaVantage, so it’s bound to have a few 
problems until the company that makes 
the extender supports more clones. 

For example, when I tried to compile 
the Ada interface for Halo (reviewed 
elsewhere in this column) on my Heath/ 
Zenith 386, my system would hang. 
Similarly, when I compiled it on my Intel 
Inboard 386, it caused a bizzare problem 
in which DOS would periodically think 
that my hard disk was not ready. I got 
through the compilation with the Inboard 
by repeatedly selecting retry in response 
to the “Drive not ready” message. 

If you expect to use extended-mode 
programs, you need to contact Meridian 
before you buy AdaVantage. The com¬ 
pany can tell you which computers the 
extenders support and which they do not. 

As I said earlier, I didn’t have any 
other problems with the compiler, so I’m 
pretty confident of AdaVantage’s relia¬ 


bility. I don’t have the test programs I 
used to evaluate version 2.1, so I can’t 
give you a precise reading on the im¬ 
provement in the code generation. I 
could use standard benchmarks, but since 
compiler vendors generally tune their 
compilers to perform well on these 
benchmarks, I don’t like to use them. In¬ 
stead, I pfefer to use typical programs 
that I write. I tried AdaVantage on two 
such programs and was pleased with its 
performance on both of them. The code 
was compact and the execution time, rea¬ 
sonable. I did notice that the compiler 
was very fast when run in real mode. 

I also tried AdaVantage on the soft¬ 
ware in the Ada Repository (see the side- 
bar “Reusable Ada software”). Again, I 
had no problems. One of the problems I 
had encountered with version 2.1 was its 
poor handling of generics. Much of the 
repository software I compiled made ex¬ 
tensive use of generics, and I had no 
problems with it. AdaVantage seems to 
handle generics correctly in version 4.0. 

The support for low-level program¬ 
ming is pretty complete now. I noticed 
only one shortcoming of any conse¬ 
quence; Address clauses are supported 
only for objects and task entries. As I 
said in the September 1988 issue, 
AdaVantage has good support for ma¬ 
chine code insertions and, with the envi¬ 
ronment support package, provides out¬ 
standing support for interfacing with 
DOS. 

Version 2.1 had limited tasking sup¬ 
port, since the task scheduler would only 
perform a task switch at synchronization 
points. Now, an optional preemptive 
scheduler allows switches on delay time¬ 
outs. This probably works fine for many 
applications, but time slicing would be 
even better. 

One version 2.1 deficiency not yet cor¬ 
rected is the lack of support for the Inline 
pragma. I really think this pragma is im¬ 
portant. With it, Ada programmers writ¬ 
ing packages in which a subprogram ap¬ 
pears in a critical path can generate the 
subprogram inline rather than have an 
actual procedure call. Meridian should 
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have implemented this pragma by now. 

Overall, I have to say that, from a 
code-generation perspective. Meridian 
has come a long way in improving the 
AdaVantage compiler. I think it could be 
a little better, but it should meet most 
needs. 

Documentation. The first thing I no¬ 
ticed about AdaVantage was the vast im- 


Reusable Ada 
software 

The Ada software repository is 
a collection of Ada software and 
documents donated to the public 
domain. I mentioned this reposi¬ 
tory in the September 1988 issue. 

I wrote that you could get it elec¬ 
tronically, but that because of the 
vast amount of source, you should 
probably get it on tape. 

Advanced Software Technology 
now provides the repository in 
DOS format on high-density disk¬ 
ettes. The full repository requires 
29 high-density diskettes. Each 
costs $10. You can buy the entire 
repository or just the ones that in¬ 
terest you. 

The last snapshot of the reposi¬ 
tory was taken in late 1988. ASR 
plans to update the version they 
distribute. I looked at the software 
on several of the diskettes and 
found it comparable to what I 
could get electronically, so I’m 
satisfied with the quality of the 
version supplied by ASR. 

As a reminder, the repository 
contains many useful tools and 
abstractions. Tools include source 
line counters, spelling checkers, 
and an Ada parser. Abtractions in¬ 
clude varying length strings, 
queues, trees, and command line 
parsers. 

The company actually special¬ 
izes in providing software design 
and development assistance, com¬ 
piler evaluations, and so forth (es¬ 
pecially with Ada) in the Long Is¬ 
land area. They provide the re¬ 
pository as a (mostly nonprofit) 
service. For more information 
about the repository or their con¬ 
sulting service, write to 

Advanced Software Technology 

5 Patricia Lane 

Patchogue, NY 11772 


provement in the form and content of the 
documentation. In version 2.1, the small 
cramped binder and poor typography 
made the documentation difficult to use. 
Moreover, the documentation seemed to 
be missing some information, and the in¬ 
dex was nearly useless. 

With version 4.0, the manual comes 
printed on letter-size paper and in a 
binder large enough to easily hold the 
documentation for all the AdaVantage 
products I’m reviewing. The improved 
use of various type styles and sizes 
makes the documentation easier to read. 
The index also seemed complete — 
every topic I looked for in the index was 
actually there. 

The content of the documentation also 
seemed complete. It has very good de¬ 
scriptions of library management, how to 
interface to other languages, and the rep¬ 
resentation of data structures — all im¬ 
portant for serious Ada programming. 

Programming environment. One 

complaint that I had about the program¬ 
ming environment in version 2.1 was that 
the DOS environment and utilities pack¬ 
ages did not come as part of the com¬ 
piler. The utilities package and DOS en¬ 
vironment library are now part of the 
professional development system. These 
packages provide many of the features 
you need to interface with DOS. With 
the utilities package you can now get to 
command-line arguments, use floating¬ 
point math functions, and perform bit- 
level operations. 

The Ada Developer Interface of ver¬ 
sion 2.1 still exists in version 4.0.1 really 
didn’t care for the ADI at all, and Merid¬ 
ian admitted that it has had many com¬ 
plaints about it. The company plans to 
offer an alternative interface soon. 

Just for completeness, I’ll mention that 
the AdaVantage debugger is superb. I re¬ 
ally like the many features it offers, such 
as variable “watchpoints” and At com¬ 
mands. It has the features you would ex¬ 
pect on a debugger for a mini or main¬ 
frame computer. 

New features. Now that I have given 
you an update on the improvements in 
AdaVantage, I want to describe two new 
features available with version 4.0: the 
Software Composition Manager and 
Booch components. (The runtime cus¬ 
tomization kit wasn’t ready in time for 
this review.) 

Software Composition Manager. If 
you are creating a large Ada program or 
many small ones, you need some way to 
control the versions and variants of your 
software. I was pleasantly surprised to 
find that Meridian offers an outstanding 
product for AdaVantage, called the Soft¬ 


ware Composition Manager. For $795, 
the SCM gives you just the control you 
need. Built on top of the Polytron Ver¬ 
sion Control System, the SCM becomes 
an integral part of AdaVantage. When 
you successfully compile an Ada pro¬ 
gram unit, SCM automatically submits it 
to version control. If for some reason 
you don’t want this to happen, you can 
use a compiler option to prevent it. 

When you link the program, a program 
configuration file is created that the 
SCM can use to rebuild this version at a 
later time. You can also tie in files that 
should be logically associated with the 
bound program, such as data files or edi¬ 
tor script files. 

When you want to rebuild an earlier 
version, you just specify the program 
configuration file and the version you 
want to rebuild. For example, to rebuild 
version 3.2 of your program, specify the 
option -R3.2 on the command line. One 
minor gripe: If you don’t specify a ver¬ 
sion, the SCM tries to rebuild the current 
version by looking for the source files in 
your current directory. I would have 
found it more useful to rebuild the last 
version submitted to version control. 

I did not review the Polytron Version 
Control System, but I will say a few 
words about it because I’d like to see 
more compilers use this really powerful 
piece of software. With the VCS, you 
can directly get and put files under ver¬ 
sion control. You can lock files and, if 
you are using a network, get a network 
version of the VCS to ensure that users 
don’t simultaneously update the same 
file. You can use the VCS directly with 
other compilers or other products, al¬ 
though you won’t have quite the ease of 
use that you do with the SCM. 

Booch components. Another pleasant 
surprise was Meridian’s packaging of the 
Booch components. These consist of 
some 500 reusable Ada software compo¬ 
nents developed by Grady Booch. He de¬ 
fined a hierarchy of reusable compo¬ 
nents, described in his book Software 
Components with Ada (Benjamin Cum¬ 
mings, 1987). The book also describes 
the implementation of selected compo¬ 
nents. Meridian has compiled all 500 
components and created a separate li¬ 
brary for each chapter in Booch’s book. 
The book and the compiled components 
are available for $250. 

The components include data struc¬ 
tures and tools. The data structures pro¬ 
vided are stacks, lists, strings, queues 
and dequeues, rings, maps, sets and bags, 
trees, and graphs. Many variants of each 
data structure are provided; for example, 
bounded and unbounded variants, vari¬ 
ants that can be used in the presence of 
concurrency, variants with garbage col- 
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lection, etc. The tools include utilities, 
filters, pipes, sorting and searching rou¬ 
tines, and pattern matching routines. 

Booch’s book devotes a chapter to 
each of the data structures and tools. 

Each chapter on data structures presents 
the implementation of a few of the vari¬ 
ants, and each chapter on tools presents 
the implementation of the tools. 

Summing up. AdaVantage 4.0 is a 
professional-quality Ada compilation 
system for the serious Ada programmer. 
While I think AdaVantage still has a way 
to go before it can match the Alsys com¬ 
pilation system, cost might be a factor. 
You don’t need 4 Mbytes of memory as 
you do with Alsys’s system, so you can 
save money there, and the basic AdaVan¬ 
tage compilation system is considerably 
cheaper than Alsys’s. You’ll still get a 
quality compiler. The tough part is de¬ 
ciding the cost/quality trade-off you are 
willing to make. It’s like trying to decide 
whether you want a Corvette or a top-of- 
the-line Porsche. I prefer the Alsys com¬ 
piler, but the good news is, you’ll proba¬ 
bly be pleased with whichever one you 
select. 

Contact Meridian Software Systems at 
10 Pasteur St., Irvine, CA 92718, phone 
(714) 727-0700. 
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Tuning your Ada 
programs 

AdaTune is another important addition 
to the Alsys tool collection. It lets you 
profile your Alsys Ada programs so you 
can find the bottlenecks and improve 
performance. It also provides coverage 
analysis so you can find out which lines 
of your program were actually tested and 
which still need to be. 

To use AdaTune for profiling, you 
first compile your program with the de¬ 
bugging option. When you use the Alsys 
binder, you specify the Tune option and 
specify tune.obj as an additional object 
module that should be linked into your 
program. Then you invoke AdaTune and 
indicate that you want to prepare for pro¬ 
filing. You can select the entire program 
for profiling or just a single program 
unit. Finally, you execute the bound pro¬ 
gram, several times if you want. Once it 
finishes executing, you can get the re¬ 
sults of the profile analysis. 

You get the results by invoking Ada¬ 
Tune again, this time selecting Profile 
Analysis. This displays a high-level pro¬ 
file of your program. The profile in¬ 
cludes global information such as the 
number of times the program was exe- 


0.0 % 

separate (Test_Tune) 
procedure T is 

0.0 % 

J : Integer := 10; 

0.0 % 

begin 

for K in 1 .. 2 loop 

31.8% 

for I in 1 .. 500 loop 

45.4% 

J := J ** 5; 

22.7% 

J := 10; 

0.0 % 

end loop; 

0.0 % 

end loop; 


end T; 


Figure 1. Detailed profile analysis. 


cuted and the total execution time. If you 
requested it, the profile contains infor¬ 
mation on the runtime system as well as 
your program. The profile results are di¬ 
vided into a runtime code portion and a 
user code portion, with the overall time 
given for each portion. The total execu¬ 
tion time for each program unit is also 
given. The display clearly marks pro¬ 
gram unit nesting. 

By positioning the cursor on the name 
of a user program unit in the profile dis¬ 
play and depressing the Enter key, you 
get a detailed analysis of the subpro¬ 
gram. (See Figure 1.) The detailed pro¬ 
file displays the relative time spent exe¬ 
cuting each line in the subprogram. 

Coverage analysis is obtained in a 
similar manner except that you can ob¬ 
tain coverage for the entire program or 
select one or more program units. The 
coverage analysis display shows the 
number of times the program was exe¬ 
cuted and, for each program unit submit¬ 
ted, the ratio of lines submitted to lines 
executed, plus, for each such unit, the 
same ratio for the program units nested 
within it. 

Again, by simply positioning the cur¬ 
sor on a program unit in the display and 
pressing the Enter key, you get detailed 
coverage analysis of the program unit. 
(See Figure 2.) Lines that were executed 
are marked with Lines that have 
code generated for them but were not 
executed are marked with “»>.” Lines 
that have no code generated for them are 
not marked. 

The analysis provided by AdaTune can 
really help improve your programs. You 
can easily find the hot spots in the pro¬ 
gram that need to be tuned and make 
sure that you’ve executed each line of 
code. 

One feature I’d like to see added to 
AdaTune is a profile that gives the num¬ 
ber of times each line of code was exe¬ 
cuted. This can help in deciding whether 
a portion of the code'takes a large 


with RTS_Test; with User_Test; 

- procedure Test_Tune is 

X : Integer := 0; 
procedure R is separate; 
procedure S is separate; 
procedure T is separate; 

begin 

RTS_Test; 

User_Test; 
for I in 1 .. 100 loop 
S; 

T; 

if X /= 0 then 
»> R; 

end if; 
end loop; 

for I in 1 .. 5000 loop 
if X /= 0 then 
»> R; 

end if; 
end loop; 

- end Test_Tune; 


Figure 2. Detailed coverage analysis. 


amount of time because it’s slow or be¬ 
cause it’s called many times. It can also 
help detect lines whose frequency of exe¬ 
cution should be a multiple of each 
other, but aren’t. 

I’m especially pleased with AdaTune 
because it makes evaluating reusable 
software easier. Reusing established soft¬ 
ware promises to increase productivity 
and reliability. One potential danger in 
reusing software arises when the per¬ 
formance of the existing software is not 
acceptable. With AdaTune, you can write 
a few simple tests (possibly just using 
the software you are developing) and de¬ 
termine whether the performance of the 
software you want to reuse is acceptable. 
If it has hot spots, you can find them and 
decide whether it’s cheaper to modify 
them or write a new version. Tools such 
as AdaTune can go a long way in encour¬ 
aging software reuse. 

As if the profile and coverage analysis 
weren’t enough, AdaTune also provides 
a really nice view capability similar to 
the one provided by AdaProbe, Alsys’s 
outstanding source-level debugger. For 
example, you can view a program with 
varying abstraction levels, such as only 
subprogram specifications or only sub¬ 
program specifications and comments. 
You can show higher level constructs, 
such as if statements, loops, and case 
statements, without showing the lower 
level statements such as assignment 
statements and procedure calls. This 
way, after getting the results of 
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AdaTune’s analysis, you can examine a 
program from various abstraction levels 
and make the changes necessary to im¬ 
prove the program’s quality. 

Using the viewer, you can position the 
cursor on an entity and ask where it is 
declared. If it is a deferred constant or a 
private type declaration, you can ask to 
be placed at its completion. 

Finally, the viewer allows you to point 
to an object and ask for a progression of 
places where the object is declared and 
used. The progression is scoped, so you 
are taken to instances of the same object, 
not the same name. As I said, these fea¬ 
tures are also provided in AdaProbe. 

One other nice feature shared by both 
AdaTune and AdaProbe is the ability to 
write the contents of a window to a file. 
Figures 1 and 2, which illustrate the de¬ 
tailed profile and coverage analysis, 
were captured by simply pointing to the 
window containing the information and 
then telling AdaTune to write it to a file. 

For those of you who have Alsys Ada 
compilers, I really recommend AdaTune. 
As far as I’m concerned, any serious Al¬ 
sys user can’t afford to do without the 
quality enhancement provided by Ada¬ 
Tune. For those who don’t have Alsys 
Ada compilers: If your vendor doesn’t 
have a tool comparable to AdaTune, 
maybe you should ask why. 

Contact the company for pricing. Al¬ 
sys is located at 67 S. Bedford St., Burl¬ 
ington, MA 01803-5152, phone (617) 
270-0030. 
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Using graphics with 
Ada 

Many applications programs need to 
produce graphics images on the screen, a 
printer, or a plotter. They also need to 
read input devices (locators) such as 
mice, trackballs, and graphics tablets. 
You can write routines to provide these 
capabilities, or you can use the Halo 
Graphics Kernel System and save your¬ 
self the time. 

Halo, which costs $995, has bindings 
for both Meridian and Alsys Ada, as well 
as for Basic, C, Fortran, and Pascal. It 
supports more than 100 graphics boards, 
50 printers, 20 scanners, 10 locators, and 
several plotters. If you load all this on 
your disk, along with a binding for one 
of the Ada compilers, you’ll need close 
to 3 Mbytes of disk storage. You can sig¬ 
nificantly reduce this by just loading 
support for the devices you need (al¬ 
though some of the storage requirement 
includes sample programs). 

The only thing I disliked about Halo is 


the installation procedure. The installa¬ 
tion instructions suggest how you should 
organize your Halo files (into five subdi¬ 
rectories) and then tells you to copy the 
seven language-independent diskettes, 
which contain more than 200 files. Fortu¬ 
nately, the limited number of file exten¬ 
sions means you can load a diskette and 
then copy the extensions to the appropri¬ 
ate directory. Halo should come with an 
installation procedure that lets you select 
whether you want to load all the files or 
just some. But, as I said, this is the only 
negative thing I have to say about the 
product. 

To use Halo, you first compile the Ada 
Halo binding for your compiler, as well 
as the program that uses the binding. 
Then you link them with an object li¬ 
brary supplied with Halo. The only limi¬ 
tation on using Halo is that you cannot 
use it in protected-mode programs. 

While I didn’t try it, you could probably 
write a normal DOS program and load it 
from your extended-mode program via a 
DOS BIOS call. Media Cybernetics plans 
to come out with extended-memory sup¬ 
port this summer. 

Describing the Graphics Kernel Sys¬ 
tem supported by Halo would take up too 
much space, so I won’t try. I’m going to 
assume you’re either familiar with the 
GKS standard or have some basic under¬ 
standing of graphics. I’ll just highlight a 
few of Halo’s features without describ¬ 
ing which are Halo extensions. You’ll 
find a good introduction to GKS in Intro¬ 
duction to the Graphical Kernel System 
by F. Hopgood et al. (Academic Press, 
1986). 

Halo can really reduce the work that 
goes into writing graphics- or locator- 
oriented programs. You can easily draw 
circles and ellipses, bars and boxes, and 
polygons. You can fill them with solid 
color or with hatching. You can read the 
position of a mouse or graphics table and 
map it into one of the coordinate systems 
provided by Halo. 

Halo also provides rubberband func¬ 
tions to support rubberband lines, circles, 
and boxes. If your graphics device sup¬ 
ports panning, scrolling, or zooming, 

Halo supports it. 

Viewports — portions of the screen 
where the graphics occur — are sup¬ 
ported, as is clipping within the view¬ 
port. Halo also provides some limited 
image movement and animation support. 

The manuals that come with Halo are 
really well written. The Library Refer¬ 
ence manual has a 30-page overview that 
discusses topics such as coordinate sys¬ 
tems and aspect ratio. In fact, the discus¬ 
sion of aspect ratio is so clear, you’ll 
easily understand when you need to be 
concerned with it and how to use it when 
you must. Each Halo function is clearly 


described. Moreover, each function de¬ 
scription includes C, Basic, and Fortran 
code fragments to illustrate its use. (It 
would be nice to have Ada and Pascal 
fragments as well.) 

The Language and Device Reference 
manual contains a description for each 
device supported by Halo. The graphics 
cards I looked at were clearly described. 

I tried running some of the sample pro¬ 
grams for the ATI VGA Wonder and 
Video-7 VRAM VGA boards, and found 
the descriptions of the boards complete 
and easy to understand. 

The Language and Device Reference 
manual also contains the language bind¬ 
ing. The Ada binding is described in 114 
pages. The manual presents the constant, 
type, and subprogram declarations in al¬ 
phabetical order. With each declaration it 
names the package in which it is de¬ 
clared and the file that contains that 
package. With the binding you also get 
several examples of how to use Halo. 
These include examples of drawing vari¬ 
ous shapes, using a locator, and image 
motion. 

One last feature of Halo I really like is 
the tutorial. The Library Reference man¬ 
ual has 16 pages devoted to a tutorial and 
a program, LearnMH, that allows you to 
execute Halo commands directly. The tu¬ 
torial takes you through a well-thought- 
out series of Halo commands using 
LearnMH. An especially nice feature is 
that you can use it to prototype your 
graphics before compiling them. This is 
especially easy because LearnMH can 
execute commands from a file. 

If you plan to write graphics programs 
on your PC and you have either the Me¬ 
ridian or Alsys Ada compilers, take a 
good look at Halo. It will save you a con¬ 
siderable amount of effort. 

Contact Media Cybernetics at 8484 
Georgia Ave., Silver Springs, MD 
20910, phone (301)495-3305. 

Reader Service 23 

Simplifying program 
composition 

The XinoTech Program Composer is a 
syntax-directed editor for composing 
programs in languages such as Ada, Pas¬ 
cal, and Modula-2. The IBM PC version 
reviewed here requires DOS 3.0 or bet¬ 
ter, 640 Kbytes of memory, and 1.5 
Mbytes of hard-disk storage. The PC ver¬ 
sion sells for $2,250 and requires a hard¬ 
ware protection block that attaches to the 
printer port. 

The Program Composer has features 
that set it apart from other syntax-di¬ 
rected editors, such as multiple language 
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views and script-building capabilities. 
The composer also has some problems. 

As a syntax-directed editor, it provides 
programmers with a powerful tool for 
composing programs. The resulting pro¬ 
gram will be nearly free of syntax errors 
and pretty printed. Designers using either 
the AdaDL or Byron design languages 
get the same benefit. 

The composer accomplishes this by 
using information it has about a particu¬ 
lar language’s grammar and the way in 
which constructs of the language should 
be formatted. As the user enters text, the 
composer makes sure the grammar rules 
of the language are being followed and 
formats the text accordingly. One of the 
problems with the composer is that a few 
situations come up in which it lets you 
make some silly mistakes. 

For example, parameters to Ada func¬ 
tions can only be input parameters, while 
parameters to Ada procedures can also 
be output parameters or input-output 
parameters. These parameter modes are 
described in Ada using the reserved 
words in, out, and in out, respectively. 
Therefore, for an Ada function, the only 
parameter mode allowed is mode in. For 
some incredible reason, the composer 
lets you specify the other two modes as 
well. These are the kinds of silly mis¬ 
takes that a syntax-directed editor should 
prevent you from making. 

Even though it lets a few errors get 
through, the composer reduces time 
wasted in using a compiler to detect syn¬ 
tax errors. Compilers use significantly 
more system resources than a syntax-di¬ 
rected editor, so the reduction can be sig¬ 
nificant, especially if you have multiple 
users in a non-DOS environment. This 
allows programmers and designers to be 
more productive. 

Typically, you would use the com¬ 
poser in developing a new module, say a 
function, from scratch. Using Ada as an 
example, you invoke the composer and 
select the “create” menu choice. Next, 
you enter the name of the file you want 
to create and specify Ada editing. The 
composer then places the compila- 
tion_unit placeholder in the program 
window. 

Placeholders come in two forms: re¬ 
quired and optional. In a subprogram 
body, at least one statement is required, 
so a required statements placeholder is 
used to indicate that some program text 
must be added there. However, in an if 
statement, the elsif part is optional, so an 
optional elsif_part placeholder is used 
there. Different attributes are used to dis¬ 
play reserved words, other Ada text, re¬ 
quired placeholders, and optional place¬ 
holders, so it’s easy to tell what’s what. 
(See Figure 3.) 

Once you are presented with the 


function "=" (u, v 

Vector) return Vector is 

Vector_Length : 

Integer := u’Length; 

Vector (1 .. Vector_Length); 

begin name 

if v'Length /= Vector_Length then 
raise Size_Error; 
end if; 
statements 
exception 

exception_handlers 
end name; 


(a) 


function "=" (u, v : 

Vector) return Vector is 

Vector_Length : 

Integer := u’Length; 

Vector (1 .. Vector_Length); 

begin name 

if v'Length /= Vector_Length then 
raise Size_Error; 

end if; 

if condition then 
statements 
elsif_part 
else 

statements 
end if; 
exception 

exception_handlers 
end name; 


(b) 



Figure 3. Program window (a) before expanding the statements template and (b) 
after expanding the statements template. 


compilation_unit placeholder, you have 
several ways to proceed. In one extreme, 
you can have the composer play a mostly 
passive role. You type in the program 
text just as you would in a standard edi¬ 
tor. The difference is that the composer 
ensures you don’t make any syntax er¬ 
rors while it formats the text. 

If you can’t remember the syntax for a 
particular construct, you can use the help 
key. The help key brings up a menu of 
allowable constructs. You select the one 
you want, and the composer supplies you 
with a template for that construct. You 
can also press the help key to complete 
the construct you are working on. For ex¬ 


ample, if you are working on an if state¬ 
ment, using the help key will add the rest 
of the if-statement template. (See Figure 
3.) 

At the other extreme, you can have the 
composer play an active role. At each 
placeholder, the help key calls up a menu 
of choices for placeholder replacement. 
You can replace the placeholders in 
whatever order you want. Each template 
shows all placeholders, required or not. 

The first extreme doesn’t make full 
use of the composer’s knowledge of the 
language as a means of reducing your 
typing. The second extreme is useful 
when you are first learning a language, 
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but gets too verbose once you have 
passed the novice stage. By default, the 
composer comes configured somewhere 
in between. As soon as the composer can 
determine which construct you are typ¬ 
ing, it completes the template, using only 
required placeholders and frequently 
used placeholders. You can also perma¬ 
nently configure the composer to reflect 
your own taste or temporarily override it. 

Editing what you have already entered 
is also simple. You can cut and paste 
with the same syntax checking and for¬ 
matting as in text entry. You can cut an 
entire construct, say a loop statement, 
and move or copy it to another portion of 
the program window. If you try to place 
it where a statement is not allowed, the 
composer will not let you. If you nest it 
with another construct, no matter how 
deeply nested, the composer will format 
the loop statement accordingly. 

The composer also has a nice session- 
based undo/redo capability. The Undo 
command will undo the effect of the last 
command. The command can be used re¬ 
petitively to undo the changes of the last 
command whose changes are still in ef¬ 
fect. The Redo command, which can also 
be used repetitively, redoes the last un¬ 
done command. The All Undo command 
undoes all command-session commands 
still in effect, while the All Redo com¬ 
mand redoes all commands undone in the 
session. The Forget Past command 
causes the session history to be forgot¬ 
ten. 

The composer has a rich assortment of 
other useful commands. For example, it 
provides a simple search-and-replace text 
capability. Windowing commands pro¬ 
vide multiwindow editing. You can in¬ 
voke your compiler from the composer 
and let the composer help you find the 
errors detected by the compiler. The 
Save command allows both text and 
composer-encoded versions of a file to 
be saved. The Text Insert command al¬ 
lows you to read in an existing text file 
and have the composer convert it to 
internal form. 

An interesting feature is the Change 
View command. If you design a program 
using AdaDL or Byron PDL notation, 
you can change the view to pure Ada to 
get a more compact view of the program. 
The composer hides the AdaDL or Byron 
comments. 

You can also get an Ada view for Pas¬ 
cal programs, although it’s not part of 
the standard distribution. To use this 
view, you first load a Pascal source file 
and change to the Ada view. The com¬ 
poser then performs a “syntax conver¬ 
sion” on the Pascal program to give you 
an Ada view. Unfortunately, the “syntax 
conversion” doesn’t produce a particu¬ 
larly good result. If you have just a few 


lines, it’s fine; otherwise, I suggest you 
use R&R Software’s PasTran if you need 
to convert Pascal to Ada. 

One other useful capability is the ses¬ 
sion replay. You can go through an edi¬ 
tor session, exit the composer, and replay 
the session when you invoke the com¬ 
poser again. This lets you build script 
files for doing common bulk editing. 

I wish I could strongly recommend the 
Program Composer, but I can’t. For 
$2,250 I expect perfection from a syntax- 
directed editor, and the composer doesn’t 
even come close. The most serious prob¬ 
lem is its lack of reliability. During one 
week’s worth of intensive use, the editor 
hung up six times. The text editor I use 
hasn’t hung up in more than five years of 
use, and it came as a throw-in with a 
text-documentation system. More than a 
year ago, I had an early version of the 
composer, which I decided not to review 
because of its lack of reliability. Since 
the company was just starting out, I 
didn’t want to give a bad review to a 
product that I thought could become one 
of the most important tools that a pro¬ 
grammer could have. I also thought that 
market pressures would result in a more 
sensible pricing structure, but I was 
wrong on both counts. 

Other aspects of the composer bother 
me, such as an apparent lack of apprecia¬ 
tion of how programmers and designers 
use tools and what they expect from 
them. For example, in Ada, the name of a 
subprogram, package, or task can be op¬ 
tionally repeated at the end of the unit, to 
help delimit the unit. Every Ada style 
guide I’ve seen suggests using the name 
at the end. EMACS editors that provide 
Ada macros insert the name at the end, 
as do other syntax-directed editors, but 
for some reason the composer does not. 
Worse, if you give a name to certain con¬ 
structs, such as a loop, then Ada requires 
that the name be repeated at the end of 
the construct or a compilation error will 
result. Again, the composer does not do 
this. In both cases, you must manually 
place the name at the end yourself. I told 
XinoTech about this a year ago, but I 
guess the company doesn’t think it’s im¬ 
portant. If the composer cost $200, 
maybe I could understand that perspec¬ 
tive even though I would still not agree 
with it, but for the price, the composer 
should take care of the smallest details. 

Other annoying details include the 
lack of control over formatting and the 
poor formatting of the source text. If you 
look at the example in Figure 3, you 
have to wonder how the spacing was ar¬ 
rived at for the function heading and the 
variable declarations. This is the so- 
called vertical view, in which certain en¬ 
tities such as variable declarations are 
vertically aligned on the colon. The man¬ 


ual warns that if this view is used, then a 
longer line length, at least 100 charac¬ 
ters, should be used. Maybe if the spac¬ 
ing were more sensible, this warning 
wouldn’t be necessary. 

After using the composer, I wouldn’t 
want to use a long line length, because it 
shifts the text in the program window 
when you get “close” to the right-hand 
side, and it does this much sooner than it 
has to. I find this annoying, especially 
since there’s no easy way to shift back 
again, and XinoTech doesn’t seem to 
have worked out a graceful way of doing 
so, either. The difficulty is compounded 
by the composer’s menus. You can’t re¬ 
move them from the screen. By default, 
you get a menu on the right-hand side. 
There’s more to the menu than will fit on 
one screen, so you have to scroll down to 
get to the rest of menu. (You can use the 
Logitech mouse that comes with the 
composer.) You can select a different 
layout that puts a single row of menu 
items across the top, but for some incred¬ 
ible reason, you can’t scroll through this 
menu with the mouse. 

Finally, I strongly dislike the use of a 
hardware protection block for the com¬ 
poser. As I’ve said in other reviews, 
these just get in the way. If I wanted to 
readily use all of the products that I’ve 
reviewed that have hardware protection 
blocks, I’d have to move my desk about 
another foot away from the wall. Maybe 
if the price were more realistic, 

XinoTech wouldn’t need one of these 
devices. 

To me, the Program Composer is an 
example of good technology poorly 
packaged. If the composer were reliable, 
more sensitive to how professional pro¬ 
grammers and designers actually use 
software tools, and cost a reasonable 
amount, I would recommend it as tool 
that programmers, designers, and their 
managers would love. For now, there are 
better, less expensive alternatives (such 
as KeyOne, reviewed elsewhere in this 
month’s column). 

Contact XinoTech Research at Tech¬ 
nology Center, Suite 213, 1313 Fifth St. 
SE, Minneapolis, MN 55414, phone 
(612) 379-3844. 

Reader Service 24 

Designing Ada 
programs 

KeyOne from LPS is a set of inte¬ 
grated tools for developing programs. It 
supports design, implementation, and 
documentation. The three tools are a hy¬ 
brid editor for implementation, a syntax- 
directed editor for design, and a struc- 
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tured documentation generator. The two 
editors are so well integrated that I really 
didn’t have to give much thought to 
which one I was in or how to get to the 
other. In fact, the two editors have so 
much functionality in common, and the 
user interface is so natural, that it’s hard 
to believe there are two of them. 

On the PC under DOS, this fantastic 
product costs $895 for the Ada version, 
$685 for the Pascal or C version, and 
$550 for the Modula-2 version. If you 
want just the hybrid editor, KeyFlex, it 
costs a low $295, but it’s only available 
for Ada or Pascal. 

The only negative about KeyOne for 
the PC is that it’s a subset of the work¬ 
station versions. LPS, an Italian com¬ 
pany, isn’t sure if there’s a big enough 
market for the PC version. It feels that 
PCs are mainly business computers (at 
least in Europe), and it doesn’t know if 
putting in the effort to bring the DOS PC 
version up to the same level as the others 
is worthwhile. That’s really a shame, be¬ 
cause the features not included on the PC 
version would make this product even 
better. There are four major features 
missing from the PC version: the ability 
to invoke your compiler from KeyOne; 
the on-line reference manual; the macro 
facility; and the ability to tailor KeyOne. 

As to what KeyOne does offer, I don’t 
think a review can do justice to it, be¬ 
cause much of its attraction lies in its 
ease of use. However, the company’s 
marketing material includes an extended 
example of the documentation and de¬ 
sign support. Here, I’ll try to give you 
some idea of why I like KeyOne so 
much. 

Like the Xinotech Program Composer, 
the KeyOne editors are syntax-directed, 
but they also provide much more. I’m 
not even going to try to distinguish be¬ 
tween KeyOne’s two editors, but if 
KeyFlex interests you as a separate prod¬ 
uct, note that it lacks the features involv¬ 
ing webs and literate programming. 

In addition to syntax-directed editing, 
KeyOne allows text editing and incre¬ 
mental syntax analysis. This means that 
you can easily enter text whenever you 
want. When you leave text mode, 

KeyOne performs syntax analysis on the 
text you entered, using as its context the 
portion of the program in which you en¬ 
tered the text. You can enter text mode 
explicitly, but most of the time KeyOne 
will recognize that you want text mode 
when you start entering text. While in 
text mode, no formatting of the text takes 
place. But when you leave text mode, the 
text is formatted while syntax is ana¬ 
lyzed. 

If during text mode you make a syntax 
error, when the syntax is checked, you 
are placed in text mode at the point 


where the error exists. You can quickly 
correct the error, and when you exit text 
mode, syntax analysis starts up again. 

Several times I tried typing in six or 
seven lines in text mode to check out the 
response of the syntax analyzer. It was 
so quick the syntax analysis and format¬ 
ting would finish before I was ready to 
hit another key. 

KeyOne’s search capability is ex¬ 
tremely powerful. While you can per¬ 
form normal text searches, you can also 
perform domain searches. For example, 
the search string 

k procedure n Valid d Sum k loop /a+b 

means search for a procedure named 
Valid that contains a declaration for Sum 
and has a loop in which the pattern a+b 
appears. Many times I have wished I had 
such a search capability — now I do. 

The editors have lots of other nice fea¬ 
tures, such as the undo capability and the 
simplicity of entering syntax with the 
prompter, but you really have to use 
KeyOne to appreciate it. LPS obviously 
spent a considerable amount of time on 
the user interface, and it shows. 

The last KeyOne feature I want to talk 
about is the documentation generator. 
Key Doc. For those of you familiar with 
Donald Knuth’s Literate Programming 
and the Web structured documentation 
system, KeyDoc is an attempt to intro¬ 
duce literate programs and webs into a 
design language without using TeX. If 
you have a design language such as 
AdaDL, Byron, or some other PDL that 
uses extended Ada comments, you can 
easily include them as webs. This means 
you can get the benefits of KeyOne with¬ 
out giving up the PDL you want or need 
to use. However, in describing KeyOne’s 
structured documentation I’ll ignore this 
aspect. 

Wherever a language construct is al¬ 
lowed, you can enter an abstraction in¬ 
stead. For example, if you are defining a 
queue package, at the place where a ba¬ 
sic declaration is allowed you can add an 
abstraction, which you might call «con- 
structors», with a few simple key¬ 
strokes. (For those of you familiar with 
Ada, even though statement labels also 
use double angle brackets, no confusion 
results.) 

When you create an abstraction, you 
provide two pieces of information. For 
example, you can give the procedure 
declarations for the constructors Add, 
Remove, Copy, and whatever else you 
feel is appropriate. This is called a re¬ 
finement. You can also produce docu¬ 
mentation for the abstraction. Similarly, 
you can add the abstractions «selec- 
tors», «iterators», «exceptions», 
«visible-data-declarations», and 


«private-declarations». 

When defining the queue package 
body, you would create an abstraction 
for each subprogram body. You can add 


A guidebook for 
surviving in the 
world of Ada 

If you need information about 
Ada topics and you don’t know 
who to contact, you might have 
trouble finding it. A great source 
for this information is the book 
Ada: Sources and Resources, pub¬ 
lished once a year. By the time you 
read this, the 1990 edition will be 
available. Based on the 1989 issue 
you can find information on 

• over 60 companies developing 
and marketing Ada compilers 

• over 30 companies providing 
tools for software development 
in Ada 

• over 30 consultants and train¬ 
ers in the Ada market 

• working groups and profes¬ 
sional organizations involved 
with Ada 

• suppliers of Ada source code 

• Ada bulletin board services 

• and a great deal more. 

The 1989 version costs $39.95 
and was well worth it. The 1990 
version promises to get better. 

Another worthwhile book is the 
annotated Ada Reference Manual. 
This version of the reference man¬ 
ual includes the pertinent sections 
from “clarifications” on the Ada 
language, so it’s very useful. It 
costs $50. 

Anyone serious about Ada 
should have both these books, dis¬ 
tributed by the Grebyn Corpora¬ 
tion. By the way, Grebyn also pro¬ 
vides a general time-sharing sys¬ 
tem and publishes a monthly news¬ 
letter, “The Info-Ada Newsletter,” 
as well as providing consulting 
services on software development 
methodologies and Ada issues. For 
more information, contact 

Karl A. Nyberg 

Grebyn Corporation 

PO Box 497 

Vienna, VA 22183-0497 

(703) 281-2194 
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abstractions to refinements also, creating 
a web of abstractions. For example, the 
body for the Copy subprogram might 
contain an abstraction for verifying that 
the target queue is large enough to hold 
the source queue and an abstraction to 
actually perform the copy. Depending on 
how the queue is implemented, the re¬ 
finement of the actual copy abstraction 
might have abstractions for each of two 
or three special cases. 

Now, what does all this get you? You 


can generate a structured document that 
presents the design in one of several 
views. Let’s use the queue package as an 
example: First, the queue package speci¬ 
fication is presented with its highest 
level abstractions, such as «construc- 
tors» and «selectors». Then, the re¬ 
finements of «constructors» are pre¬ 
sented, along with all of their refine¬ 
ments, and so on. Each refinement is 
given a section number, also used as a 
subscript of the abstraction. This helps 


you locate refinements. 

If you follow the web formed by the 
abstractions and their refinements, you 
are actually looking at a tree of stepwise 
refinements. This is outstanding docu¬ 
mentation for someone trying to under¬ 
stand a design. By appropriately refining 
each abstraction, you can eventually 
come up with the actual implementation, 
as well. 

As an added touch, you can optionally 
have each refinement framed in a box 


Review notes 

Business forms. Qume Corp., 500 
Yosemite Dr., Milpitas, CA 95035, 
phone (408) 942-4000, offers a family 
of easy-to-use business software 
priced at less than $50 each. With 
them you can create presentations, 
generate and fill in standard business 
forms, or maintain mailing lists and 
create labels. Known as Qumatic In¬ 
stant Business Software, each product 
comes on both 5.25- and 3.5-inch 
diskettes. 

I had a chance to look at Instant 
Forms, which provides 22 prede¬ 
signed forms you tailor for your busi¬ 
ness. Tailoring means adding your 
company name and supplying infor¬ 
mation in fields appropriate for the 
invoice, purchase order, statement, 
sales order, facsimile, job estimate, 
proposal, and letterhead templates 
that come prepackaged. Since you 
have no control over the form layout, 
all input to the forms is textual and of 
the form “fill in the blanks." Output 
on a laser printer is excellent and uses 
the built-in fonts supplied with the 
software. A sufficient number of dot 
matrix as well as laser printers are 
supported to make this software us¬ 
able on just about any PC with a hard 
drive. 

The instruction sheet gets you 
started on the simple installation, 
aided by the highly automated install 
program. After installation the system 
generates a nine-page product intro¬ 
duction on the printer you’ve just in¬ 
stalled. Next you enter your company 
information (printed on every form) 
and choose which forms you want to 
generate. A simple on-screen menu 
includes choices for selecting, copy¬ 
ing, filling in, editing, deleting, and 
printing a form. On-line help is avail¬ 


able using the FI key. To allow you to 
generate as many different versions of 
the same form as you might desire (say, 
for more than one company), you must 
make a copy of a master form before you 
can edit or print it. 

This $44.95 software does exactly 
what it claims, namely, generates a set of 
commonly used business forms. For the 
small business person who doesn’t want 
to use an automated accounting system, 
it’s a perfect solution. About the only 
thing missing is a way to cut and paste 
information between a spreadsheet and 
this form generator. — R. Eckhouse 

Convenience software. Among the 
best values for the money is the Avery 
LabelPro. This versatile and easy-to-use 
software creates laser printer labels for 
every imaginable purpose. It offers a 
flair not found in other packages because 
it includes the ability to incorporate 
graphic images, either those included 
with the package or your own PCX files. 
To get you started, they’ve thoughtfully 
included three blank sheets of 15 differ¬ 
ent sets of gummed labels, as well as a 
set of overhead transparencies. 

From the automated installation to the 
creation, preview, and printing of the la¬ 
bels, LabelPro guides the novice user to 
turn out professional-looking results. Us¬ 
ing menu systems, built-in forms, and 
edit screens, the user moves from design¬ 
ing forms and filling in fixed fields, to 
saving and recalling such forms for print¬ 
ing, to merging data from its internal da¬ 
tabase. LabelPro also accepts informa¬ 
tion from dBase, WordPerfect Merge 
fields, and any program that can generate 
comma-delimited ASCII files. 

An excellent manual comes with the 
software (shipped on both 3.5- and 5.25- 
inch disks). It takes you through installa¬ 


tion to a finished product in only min¬ 
utes. I really appreciated the calibration 
sheet that Avery includes to make sure 
you get near-perfect alignment when 
printing your labels. Also thoughtfully 
included is a troubleshooting section in 
the manual covering installation prob¬ 
lems (you’ll need a hard disk with 1.5 
Mbytes of free space and 400 Kbytes of 
free memory), a discussion of common 
errors, and printer facts. They do not 
supply a toll-free number for technical 
support. 

You can generate from 80 to six labels 
per sheet. Different form types apply to 
each sheet: some with text only; some 
with text and a graphic; and some with 
text, a graphic, and separating bars. 
Interestingly, the transparency form en¬ 
forces good stylistic practice by limiting 
the number of lines you can generate. 
The laser printer labels as well as the 
mailing labels do away with the need for 
purchasing custom printed labels unless 
you need color. And a set of quick forms 
allows you to print sets of commonly 
used “no smoking,” “first class,” “frag¬ 
ile,” “please rush,” etc. stickers for your 
everyday jobs. 

Two downloaded fonts included with 
the package, Arial and Times, can be 
scaled from 6- to 96-point size in nor¬ 
mal, italic, or bold. Additional fonts can 
be purchased, as well as a scanning serv¬ 
ice for your custom clip-art. Three clip¬ 
art packs are available. The most inter¬ 
esting is the accessory package with 
three fonts, 20 special-purpose labels, 50 
additional label templates, 10 graphic 
borders, and 20 clip-art images. 

What do you need to use LabelPro? 
Just about any PC will do, as long as it 
has some form of a graphics display 
(CGA, EGA, VGA, MCGA, Hercules, or 
plasma), 512 Kbytes of memory, floppy 
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and/or have vertical and horizontal lines 
connecting the portions of control struc¬ 
tures. I never liked this idea, but, with 
small refinements, I found it enhanced 
the readability of the document. 

Abstractions and refinements are also 
useful for interactive browsing. If you 
position the cursor at an abstraction, hit¬ 
ting the F4 function key brings up a win¬ 
dow containing the refinement. Hitting 
Shift-F4 takes you back to the abstrac- 


and hard disk drives, and a laser printer. 
This well-done $99.95 package is avail¬ 
able from your local office products or 
computer dealer. It is packaged by Avery 
Commercial Products Division, 818 Oak 
Park Rd., Covina, CA 91724-3624, 
phone (818) 915-3851. If you’re like me 
and want a simple and fun way to pro¬ 
duce labels, this is the package to buy. 

— R. Eckhouse 

Keyboard/trackball combined. As 

you probably know, keyboards differ 
enough that each of us has a preference. 



Changing from one keyboard style can 
take some getting used to. As a result, 
some reviewers might consider an un¬ 
usual design a reason for dismissing or 
panning a product. In my case it’s pre¬ 
cisely what makes reviewing a product 
with a different approach so interesting. 
Using the Mighty KeyBoard from 
Qumax means learning where some of 
the extra keys are located and how to 


By the way, the use of the function 
keys I just mentioned is one of the many 
indications that LPS gave a great deal of 
attention to the user interface. If an ac¬ 
tion has an opposite action associated 
with it, and the action can be invoked 
with a function key, then using the shift 
key with that same function key per¬ 
forms the opposite action. 

I recommend KeyOne to anyone look¬ 
ing for a product to help in designing, 
implementing, and documenting soft- 


manipulate the trackball (Microsoft com¬ 
patible) built in to this device. 

I have become a confirmed trackball 
user since acquiring one last year. Hav¬ 
ing previously used a mouse, I had no 
trouble rolling the ball in the palm of my 
hand while pressing the buttons located 
above the ball. In the Mighty KeyBoard, 
the trackball is slightly smaller (no prob¬ 
lem), conveniently located to the right of 
the keyboard, with the buttons at the bot¬ 
tom. This change has taken me some 
time to get used to, since I had to read¬ 
just to rolling the ball with my fingers 
and pressing the buttons with my thumb. 

The key layout differs in the place¬ 
ment of the LEDs (for Num, Caps, and 
Scroll Lock) to the left of the function 
keys, no separation between the groups 
of four function keys, and the relocation 
of the cursor/screen keypad. The reduced 
size of the insert and plus keys means 
the cursor keys fit easily between the 
main keys and the numeric keypad. But 
this means both are not as large as on my 
“more standard” 101-key keyboard. It 
also allows Qumax to locate the screen 
keypad above the numeric keypad, with 
the keys themselves not quite as high as 
the top row of the numeric keys. 

Is it worth it? Absolutely! After a few 
hours of practice I am just as proficient 
on the Mighty KeyBoard as I was on my 
old keyboard. That’s quite a feat, since I 
use a communications program that re¬ 
maps the numeric and screen keys to 
emulate a VT100. But what I like best is 
the “feel” of the keyboard. It seems com¬ 
pact, yet just the right size. Key pressure 
is firm yet light. A mechanical key click 
is something new for me and I’ve come 
to like it. Having the trackball fixed to 
the keyboard is a real plus. Trackball ac¬ 
tion is smooth, and the three-button de¬ 
sign includes a sticky feature when emu- 


ware. Even if you already have an editor 
that you like, you should still consider 
KeyFlex. I doubt any other editor on the 
market even comes close to the ease of 
use and usefulness of KeyFlex. 

Contact LPS at 2225 Manchester Ave., 
#2, Cardiff, CA 92007-1932, phone 
(619) 942-4291 or LPS s.r.l., 25 Via 
Napione, 10124 Torino, Italy, phone (39) 
11-831-830 or 11-885-934. 

Reader Service 25 


lating a Microsoft mouse. And the lo¬ 
cation of the LEDs to the left means I 
am finally aware when I have inad¬ 
vertently left the Caps Lock key on. 

Unlike some other keyboards with 
built-in tracking devices, this key¬ 
board features a single cable splitting 
into twin plugs for the keyboard DIN 
connector and the 9-pin serial track¬ 
ball input. A 9-to-25 pin adapter is 
included if your machine doesn’t fol¬ 
low the new standard. Users with ma¬ 
chines having the keyboard connector 
in the front and the serial connector in 
the back of their machines will re¬ 
quire an extension of the Y-cable — 
it’s just too short in these cases. 

By the way, you can purchase the 
KT-30 keyboard without the trackball 
as the QX-301, if a compact keyboard 
is your goal. The trackball is then 
sold as the TB-30. The price for the 
KT-30 is $149.95 or $169.95 if you 
want the Dr. Halo graphics software 
as well. This unusual and delightful 
keyboard is available from Qumax 
Corp., located at 2380 Qume Dr., 

Suite D, San Jose, CA 95131, phone 
(408) 954-8040. — R. Eckhouse 

hDC MicroApps. hDC recently in¬ 
troduced two new MicroApps to go 
with Windows Manager (see Com¬ 
puter, Nov. 1989, p. 84) called Art 
Gallery and Card Maker. If there ever 
was a reason to buy a color laser 
printer, these MicroApps are it. Full 
of color, with on-line help, the two al¬ 
low you to clip and display artwork as 
custom-designed greeting cards for all 
occasions. 

When called up. Card Maker ap¬ 
pears as four panels to be filled in. 

The panels correspond to the front, 
inside left, and inside right (top and 
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bottom) of the greeting card. You paste 
bitmaps, pictures (metafiles), or text into 
the panels, then send the result to any 
printer supported by Microsoft Windows. 
You do not need a laser printer. 

The size of the panels is fixed, and 
generally images are scaled to fit to fill 
the panel as best they can. The results 
look much better for pictures because, 
unlike bitmaps, they can be redrawn to 
size since they are constructed of com¬ 
mands rather than pixels. 

The clipboard is the means of transfer, 
so any Windows applications (paint pro¬ 
grams and word processors) can be used 
to cut and paste between the apps and 
Card Maker. The Art Gallery is used to 
select predefined pictures from one of 
the five libraries included with it. You 
can also use the Art Gallery to save im¬ 
ages created with paint or drawing pro¬ 
grams. 

The cards are fun to make and offer a 
diversion when you get tired of the nor¬ 
mal applications you run on your PC. 
You’ll need Microsoft Windows and 
hDC Windows Manager to run this soft¬ 
ware. The $49.95 Card Maker package is 
available from hDC Computer Corp., 
6742 185th Ave. NE, Redmond, WA 
98052, phone (206) 885-5550. 

— R. Eckhouse 

TechStaff Tools Collection version 
1.01 is a two-disk set of utilities for IBM 
PC-compatible systems. The product in¬ 
cludes 13 programs, ranging in useful¬ 
ness from a mouse testing program and a 
Norton’s “SI” type system status pro¬ 
gram to a Fahrenheit-Celsius converter. 
The programs come with a small printed 
manual as well as some documentation 
files on disk. 

TMT is a mouse tester. It will test 
mouse existence, sensitivity, and button 
action. Any package that uses a mouse 
can do this, but TMT is a small, fast¬ 
loading program that does it easily. It 
will also test all sorts of mice, regardless 
of manufacturer. 

TDT, or Disk Tally, totals file sizes 
for a given file specification. This is use¬ 
ful when you need to see how much 
space a set of files will take before you 
copy them. For example, TDT *.COM 
gives you the disk space used by all the 
.COM files in the current directory. This 
is complemented by TFS, or Free Space. 
TFS displays the bytes remaining on the 
specified drive. So when you need to 
copy a group of files from one place to 
another, these two programs might help 

TFF is a useful utility that will find all 
copies of a named file on a disk or disk¬ 
ette, create a listing file, and sort the list¬ 
ing file by various parameters. TSI is a 
system information utility. It will tell 


you how much memofy the system has, 
coprocessor status, video adapter type, 
and other similar information. 

The rest of the programs include a file 
manager for mass copying and deleting, 
a time-stamp manager to modify file 
dates, and a huge file viewer. The latter 
does not handle files as large as memory 
and seems limited to files up to 318 
Kbytes. TPP is the Page Printer. With it 
you can print multiple copies of files, 
with various options. 

Several programs included are redun¬ 
dant. One shows you the capacity of a 
disk, as do the DOS commands Dir and 
Chkdsk. TFE tells you if a file exists, 
also like the Dir command. TVL changes 
the label of a volume, just like the DOS 
Label command. 

Some of these utilities could be very 
useful in batch programs. Unfortunately, 
they are all strictly screen oriented, limit¬ 
ing their usefulness. The designers might 
take a look at the traditional Unix phi¬ 
losophy of designing tools so they can be 
used together easily and simply, with 
pipes and output redirection. 

The package costs $29.95 and is also 
available as shareware. The programs in¬ 
cluded in this package make up a moder¬ 
ately useful package at a reasonable 
price. As a system manager, I find tools 
like these handy to keep around. Contact 
TechStaff Corp., 64 Carroll St., Water- 
town, MA 02172, phone (617) 924-0306. 
— Q. Fennessy 

PC diagnostics. Checklt from Touch- 
Stone Software, 909 Electric Ave., Seal 
Beach, CA 90740, phone (213) 598- 
7746, is an invaluable collection of PC 
diagnostic tools. With this one product 
you can glean all the system information 
(such as configuration, interrupts, and 
device drivers), run a myriad of tests on 
everything within the system (including 
the motherboard, memory, and all I/O 
devices), gather system benchmarks, and 
use built-in tools to fix problems (like 
locating bad RAM chips, setting the real¬ 
time clock, or reformatting the hard 
disk). 

This $149 package is a complete diag¬ 
nostic system for your PC or compatible. 
It will detail your PC’s configuration, 
test your hardware, and measure your 
system’s performance using industry- 
standard benchmarks. It does this 
through a series of pull-down choices 
from a menu bar. The results of the tests 
can be displayed on-screen and sent to 
the disk or printer or both. Each step of 
the way, messages and instructions are 
displayed on-screen, and context-sensi¬ 
tive help is available by using the FI 
key. 

Two things make Checklt especially 
valuable. First, the system information 


screen gives you all the details of the 
hardware and software installed on your 
machine, while the interrupts screen 
shows the current assignment of both the 
hardware interrupt lines (IRQs) and 
DMA channels. If you have an AT-class 
machine (a 286 or 386), the CMOS table 
shows the configuration stored in the bat¬ 
tery-backed CMOS memory. And for 
those familiar with device drivers, the 
screen with this information shows the 
attributes, minimum DOS version re¬ 
quired for the driver, and characteristics 
of the device driver. You do not need to 
open up the system and start poking 
around to find what is and isn’t present. 

Second, the various system tests give 
you an important confidence check to 
know that the hardware is operating cor¬ 
rectly and, if it is not, most likely what 
the problem is. For example, everyone 
on occasion seems to have a memory 
problem. Checklt can perform either a 
quick or full test on the memory, report¬ 
ing what it finds. Checklt includes a 
RAM chip locator function, which can 
even pinpoint the bad chip(s) as long as 
you can explain to Checklt how the 
memory chips are arranged. Equally im¬ 
portant tests check the hard and floppy 
disks, the serial and parallel ports, the 
video board, the keyboard, the mouse 
and game ports, and, of course, the CPU 
and numeric coprocessor chips. 

The Checklt software comes on both 
3.5- and 5.25-inch floppies. It seems to 
run on nearly any configuration as long 
as you use DOS 2.0 or later. Installation 
is a matter of copying the system files to 
a hard or floppy disk. When you start 
Checklt, it tries to determine some of the 
characteristics of your machine (such as 
the BIOS manufacturer, the system com¬ 
ponents, how much memory you have, 
and if you have a mouse). It then 
switches you into menu mode, from 
which you can individually test the sys¬ 
tem components or batch the tests to run 
through several of them, covering speci¬ 
fied devices for a preset number of 
times. 

The well-done manual explains every¬ 
thing carefully and in great detail. For 
example, the wiring for the connectors 
used in the serial and parallel loopback 
tests are included, and there is a useful 
printer test to verify that your HP Laser¬ 
Jet printer works in both text and graph¬ 
ics modes. 

All in all this is a very valuable piece 
of software to own. It is machine inde¬ 
pendent, tests and diagnoses problems, 
and comes with a lifetime upgrade guar¬ 
antee (you are entitled to any new release 
at a fee not more than 15 percent of the 
current suggested retail price). I’m glad 
to own a copy of Checklt and highly rec¬ 
ommend it to you. — R. Eckhouse 
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Spring 1990 


Dear Leaders of the Computer Industry: 

In ! 985, CONVEX delivered the C1, the world's first affordable supercomputer. In 1988, we intro¬ 
duced the C2 series of supercomputers which offer up to 10 times the performance of the C1. 
During the past five years, we have installed more than 600 CI and C2 computer systems in 33 
countries — making us the world's leading supplier of affordable supercomputers. Now, 

CONVEX is developing a new generation of supercomputer products that will continue our tradi¬ 
tion of technological leadership. 


HELP DEVELOP THE NEXT GENERATION SYSTEM 
FOR THE WORLD'S MOST SUCCESSFUL PRODUCER 
OF AFFORDABLE SUPERCOMPUTERS 


If you desire exposure to state-of-the-art technology, have a BSCS or BSEE degree and 3 + years 
experience in the development of analysis and verification software for high-performance com¬ 
puter systems, CONVEX has the challenge for you! 

If you possess excellent people skills, a strong background in computer hardware and software, 
and you are interested in the challenge and rewards of technical management, apply for our 

Design Verification Manager position. 

If you enjoy programming, are interested in logic simulation, and desire to work with some of the 
sharpest people in the industry, then talk to us about a position as a Design Verification 
Engineer. 

If you are a Software Developer who's a super sleuth and wants to play the ultimate computer 
game, inquire about our openings for Fault Isolation Engineers. 

Or, if you love to write, have a strong background in computer hardware, and desire to work 
with the latest electronic publishing equipment, ask us about a position as a Hardware 
Technical Writer. 

Headquartered in Richardson, Texas, a suburb of Dallas, CONVEX provides each employee with 
the latest development tools and an environment that truly encourages individuals to think inde¬ 
pendently and creatively. CONVEX offers its employees outstanding quality-of-life options, 
including nationally ranked school systems, a low cost of living, good cultural amenities, a mild 
climate, and no state income tax! 

We are confident that you will welcome the CONVEX Challenge. Contact us today! 


Sincerely, 



Convex Computer Corporation 


P.S. For more information about these leading edge supercomputing opportunities and to ar¬ 
range an interview appointment, please forward your resume, in confidence, to: R. Vestal, 

CONVEX Computer Corporation, 3000 Waterview Parkway, P.O. Box 833851, Dept. 
IEEE, Richardson, Texas 75083-3851. 

Or, contact us by FAX (214/497-4500J, or send e-mail to: vestal @ convex.com. CONVEX is an 
equal opportunity employer. Principals only, please. 







CALL FOR PAPERS 



COMMITTEES 

Steering Committee: 

C.V. Ramamoorthy, 

University of California, 
Berkeley 

P. Bruce Berra, Syracuse 
University 
Benjamin W, Wah, 

University of Illinois 
John Carlis, 

University of Minnesota 
Joseph E. Urban, 

Arizona State University 
General Co-Chairpersons: 

Ming T. (Mike) Liu, 

Ohio State University 
Tadao Ichikawa, 

Hiroshima University, Japan 
Program Co-Chairpersons: 

Nick J. Cercone, 

Simon Fraser University, 
Canada 
Mas Tsuchiya, 

Sypex International, USA/Japan 
Program Vice-Chairpersons: 
Mohan Ahuja, 

Ohio State University 
Ahmed K. Elmagarmid, 

Purdue University 
Kuichi Furukawa, ICOT, Japan 
Randy Goebel, 

University of Alberta, Canada 
Roger King, University of 
Colorado 

Masaru Kitsuregawa, 

University of Tokyo, Japan 
Raymond Liuzzi, USAF RADC 
Akifumi Makinouchi, 

Kyushu University, Japan 
Kyu-Young Whang, 

IBM Watson Research Center 
Clement T. Yu, 

University of Illinois at Chicago 
Tutorials Chairperson: 

Amit P. Sheth, Bellcore 
Industrial Coordinator: 

Akihiko Yamada, 

NEC Corporation, Japan 
European Coordinator: 

Witold Litwin, INRIA, France 
Awards: 

David Cohen, Sente Corporation 
Publicity: 

Ted M. Sparr, 

University of New Hampshire 

Treasurers: 

Yao-Nan Lien, AT&T Bell Labs 
Tohru Kikuno, 

Osaka University, Japan 


Seventh International Conference on 
Data Engineering 

April 8-12, 1991 
Kobe, Japan 

Sponsored by the IEEE Computer Society 

SCOPE 

Data Engineering is concerned with the semantics and structuring of data in information systems design, 
development, management, and use; and with computer system and architectural considerations that are 
relevant to that concern. It encompasses both traditional and emerging issues and applications. The purpose 
of this conference is to provide a forum for the sharing of practical experiences and research advances from 
an engineering point of view among those interested in automated data and knowledge management. Our 
expectation is that this sharing will enable future information systems to be more efficient and effective, and 
future research to be more relevant and timely. 

We are particularly soliciting industrial, business, and government participation. We know it is vital that 
there be a dialogue between practitioners and researchers. We look forward to reports of information 
systems experience detailing experiments, evaluation, problems, and opportunities associated with design, 
implementation, and operation. Such reports will be given special consideration. 



TOPICS OF INTEREST INCLUDE BUT ARE NOT LIMITED TO 


AI and Knowledge Based Systems 
Applications and Application Systems 
Benchmarks and Performance Evaluation 
Design and Human Interfaces 
Data Engineering Tools and Techniques 
Database Design and Modeling 
Database Management and Structure 
Deductive and Extensive Databases 


Distributed Database Control 
Distributed Database Systems 
Integrity and Security Techniques 
Learning and Discovery in Databases 
Object-Oriented Database Systems 
Query Languages and Processing 
Scientific Databases 
Supercomputer Databases 


PAPER AND PANEL PROPOSAL SUBMISSIONS 

Each paper’s length should be limited to 8 proceedings pages, which is about 5000 words, or 25 double 
spaced typed pages. Five copies of completed papers or panel proposals should be mailed before July 1, 
1990 to: 

Nick J. Cercone, Center for Systems Science, Simon Fraser University, Burnaby, British Columbia, 
Canada, V5A 1S6; (604) 291-3229, Nick@CS.SFU.CA 

TUTORIALS 

The day preceding the conference will be devoted to introductory tutorials which may provide the 
background for the conference proper. The day following the conference will be devoted to the advanced 
tutorials. Proposals for tutorials on data engineering topics are welcome. Send proposals by July 1, 1990 to: 
Amit P. Sheth, Bell Communications Research, RRCIJ-210,444 Hoes Lane, Piscataway, NJ 08854, USA, 
(201) 699-3300, Amit@CTT.Bellcore.Com . 


CONFERENCE TIMETABLE AND INFORMATION 


Papers and Panel Proposals Due: 
Tutorial Proposals Due: 
Acceptance Letter Sent: 

Camera Ready Copy Due: 
Tutorials: 

Conference: 


July 1, 1990 
July 1, 1990 
November 1, 1990 
January 1, 1991 
April 8 and 12, 1991 
April 9-11, 1991 


For further information contact the General Co-Chairperson, Ming T. (Mike) Liu, Department of Computer 
and Information Science, Ohio State University, 2036 Neil Avenue, Columbus, OH 43210-1277, USA, 
(614) 292-1837, Liu@CIS.IRCC.Ohio-State.Edu. 


AWARDS, STUDENT PAPERS AND SUBSEQUENT PUBLICATIONS 

Awards will be given to the best paper and to the best student paper (denoted as such when submitted solely 
by students). The latter will receive the K.S. Fu award honoring one of the early supporters of the 
conference. Up to three grants of $500.00 each will be available to help defray travel costs of student 
authors. Outstanding papers will be considered for publication in the IEEE Computer Society publications: 
Computer, IEEE Expert, IEEE Software, IEEE Transactions on Knowledge and Data Engineering, etc. For 
more information contact the general chairperson. 








NEW PRODUCTS 


Contact or send releases to Nancy Hays, Computer, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720; Compmail +, n.hays 


Wang adopts Unix in hardware, software products 


Wang has announced new hardware 
and software products based on the Unix 
environment. Two midrange systems 
start the new Open/Server family, while 
Unix ClearView provides a graphical 
desktop manager and WP/x provides 
word processing capabilities. 

The Open/Server systems incorporate 
Intel’s 486 or 386 microprocessor run¬ 
ning at 25 MHz and employ the Multibus 
II architecture. They support up to 384 
Mbytes of system memory, with 4-64 
Mbytes on the processor board. The sys¬ 
tem cabinet has a 10-slot Multibus II 
backplane, with two slots taken by the 
basic system boards. The cabinet also 
contains eight bays for 5.25-inch half¬ 
height internal drives. 

Each base system has three serial 
ports, one parallel port, and one internal 
and one external SCSI port. The systems 
can be configured with 145 Mbytes to 2 
Gbytes of internal disk storage. 

Optional communications coproces¬ 
sors provide support for local area net¬ 
works and wide-area networks. The LAN 
coprocessor is based on the 32-bit Intel 
386SX microprocessor. It supports the 
802.3 LAN connections, including TCP/ 
IP, OSI, and XNS protocols. The WAN 
coprocessor supports SNA or X.25. 

Open/Server systems can be config¬ 
ured with either SCO Unix System V/ 
386 Release 3.2 for a multiuser host en¬ 
vironment or SCO Open Desktop for a 


client-server architecture. 

An Open/Server system with a 386- 
based file and application processor with 
cache, 4 Mbytes of memory, a 1.2-Mbyte 
disk drive, and a 150-Mbyte streaming 
tape drive costs $22,690. A 486-based 
system with 4 Mbytes of memory, a 1.2- 
Mbyte disk drive, a 145-Mbyte disk 
drive, and a 150-Mbyte tape drive costs 
$27,690. 

A 10-Mbps 802.3 LAN controller with 
four serial and four parallel ports costs 
$5,995. A WAN card is $4,695. A mul¬ 
tiport asynchronous controller costs 
$2,995. A memory expansion board costs 
$3,495. 

SCO Unix costs $1,790, while SCO 
Open Desktop with Unix ClearView is 
$4,980. 

Unix ClearView consists of four appli¬ 
cations: Folder, Access, Map, and Calen¬ 
dar. Folder handles file management, dis¬ 
playing objects as icons. Access allows 
users to replace Unix names with short¬ 
cut keys to frequently used objects and 
their tasks. Map shows a graphical view 
of a user’s file system hierarchy, display¬ 
ing multiple levels of objects in two 
panes simultaneously (directories and 
files). Calendar is a scheduler and re¬ 
minder. 

Unix ClearView will be bundled with 
all Wang platforms running SCO Open 
Desktop, with shipments scheduled for 
the second quarter of 1990. 



Wang’s Open/Server systems support 
up to 128 users. 


WP/x features pop-up menus, function 
keys, and on-screen help. It provides a 
thesaurus, a spelling and usage checker, 
editing tools, and special features, in¬ 
cluding revision tracking, redlining, 
floating footnotes, and a special terms 
dictionary. It runs under SCO Xenix and 
Unix. 

Open/Server: Reader Service 30 
ClearView: Reader Service 31 
WP/x: Reader Service 32 


Prime adds high-end 
systems to 50 Series 

Prime Computer has announced two 
high-end systems, the uniprocessor 6450 
and dual-processor 6650, in its 50 Series 
family of superminicomputers. Accord¬ 
ing to the company, both systems are 
based on VLSI ECL components. 

The new systems support up to 512 di¬ 
rectly connected users and 960 users 
within an Ethernet network. The basic 
package includes two 817-Mbyte disk 
drives with a controller and the Primos 
operating system. 

A 6450 basic system package with a 



Prime’s 6450 and 6650 superminicom¬ 
puters come in two-bay cabinets occu¬ 
pying about 13 feet of floor space. 


four-board processor and 32 Mbytes of 
memory costs $470,845. A 6650 basic 
system package with an eight-board 
processor and 64 Mbytes of memory 
costs $772,845. 

Higher level packages including 64 
Mbytes of memory, six 817-Mbyte disk 
drives with three controllers, 32 asyn¬ 
chronous lines, and two peripheral cabi¬ 
nets cost $607,347 for the 6450 and 
$877,347 for the 6650. Both systems 
support up to 32 disk drives and eight 
disk controllers, 32-128 Mbytes of main 
memory, and up to 26.1 Gbytes of mass 
storage. 
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HP uses RISC in 3D workstations 



Hewlett-Packard’s HP 9000 Models 834SRX and TurboSRX 3D workstations 
feature increased power in the graphics subsystems. 


Hewlett-Packard has announced two 
3D workstations based on its Precision 
Architecture, a reduced instruction set 
computing technology. The HP 9000 
Model 834SRX and Model 834 Turbo 
SRX are new configurations of the 
Model 834 introduced in October 1989. 
The new models reportedly provide 14 
MIPS of processing power. 

Models 834SRX and TurboSRX come 
standard with 8 Mbytes of RAM (ex¬ 
pandable to 96 Mbytes), a 19-inch color 
monitor with a resolution of 1,280 x 
1,024, a keyboard, and a mouse. They 


Aldus upgrades Pagemaker 

Aldus plans to ship Pagemaker 4.0 in 
the second quarter of 1990. The new ver¬ 
sion of the company’s desktop publish¬ 
ing program reportedly contains more 
than 75 new features and enhancements. 

A new Story Editor provides an alter¬ 
native text-only window for word pro¬ 
cessing. Version 4.0 also provides more 
text controls, including an expanded 
type-specification dialog box, and in-line 
graphics, a feature that automatically 
links graphics to the corresponding text 
as the user makes editing and layout 
changes. 

A new links management feature in¬ 
forms users of changes in text or graph¬ 


can connect to seven human-interface 
devices simultaneously and have an ex¬ 
pansion slot available. 

Base prices are $34,900 for the SRX 
and $37,900 for the TurboSRX. 

The new systems are also available 
with a software option that provides a 
preinstalled and configured X Window 
System on a 304-Mbyte hard disk. The 
preloaded software option is bundled at 
no extra charge on an HP-IB hard disk 
drive, which costs $5,675. 
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ics files placed in a Pagemaker layout. 
Users can then choose to automatically 
update the layout with the most recent 
version of those files whenever changes 
are made in the source files. 

The company says it has added a spell¬ 
ing checker and a search-and-replace 
command in response to direct requests 
by customers. The search-and-replace 
function can find and replace letters, 
phrases, fonts, point sizes, and paragraph 
styles. 

Along with other text-control capabili¬ 
ties, Pagemaker 4.0 offers point-size-in- 
dependent tracking, which allows users 
to adjust text spacing, and kerning of let¬ 
ter pairs. A separate Table Editor utility 
allows users to build tables, save them in 


End users get neural net 
workstation 

Hecht-Nielsen Neurocomputers has an¬ 
nounced a commercial end-user neural 
network workstation called IDEPT (Image 
Document Entry Processing Terminal). 
The new computer comes with intelligent 
character recognition capabilities and Os¬ 
car, the company’s proprietary neural net¬ 
work recognition software. 

According to HNC, IDEPT recognizes, 
captures, stores, and retrieves images. It 
reads forms scanned into the system.The 
Oscar software reportedly recognizes 
hand-printed characters and numbers (seg¬ 
mented or touching), typed characters, and 
printer-generated characters. It also recog¬ 
nizes marks such as checked boxes on 
forms or circled letters or numbers. 

The workstation can operate in stand¬ 
alone or networked configurations. In a 
network, IDEPT can work with forms ei¬ 
ther stored on a remote image data sys¬ 
tem or scanned in at another location. 

The IDEPT workstation includes an 
IBM PC AT-compatible, HNC’s Anza 
Plus neurocomputing processor, an opti¬ 
cal scanner with a document feeder, a 
color VGA monitor, and Oscar software. 
The basic configuration costs $39,500. 

Options include an optical WORM 
disk storage device, Ethernet intercon¬ 
nects, and printers. 

HNC has also announced the Anza 
Plus/DP neurocomputing coprocessor for 
PC AT computers and Sun workstations. 
The accelerator boards come with 16 
Mbytes of RAM. The Sun version ex¬ 
pands up to 64 Mbytes of RAM. With 16 
Mbytes, the Anza Plus/DP costs $19,500 
for the PC version and $27,500 for the 
Sun version. 
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PICT format, and place them in a Page- 
maker layout. Tables can include both 
text and graphics. 

The company recommends a system 
configuration of an Apple Macintosh 
Portable, SE/30, II, IIx, Ilex, or Ilci, plus 
a hard disk and 2 Mbytes of RAM. The 
minimum configuration is a Mac Plus or 
SE with 1 Mbyte of RAM and a 20- 
Mbyte hard disk drive. Pagemaker 4.0 
supports Quickdraw- and Postscript- 
compatible printers. 

Pagemaker 4.0 will retail for $795. 
Registered owners of Pagemaker 3.0 can 
upgrade for $150 by calling Aldus Cus¬ 
tomer Services at (800) 942-9488. 
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Motorola slates general sampling of 68040 


Motorola has scheduled general sam¬ 
pling of its new 32-bit microprocessor, 
the 68040, for the end of the first quarter 
of 1990. According to the company, at 
25 MHz the 040 delivers 20 MIPS, an 
average of 3.5 Mflops, and a peak of 8 
Mflops. 

The chip includes an integer unit, 
floating-point unit, two memory manage- 


Intel Scientific Computers has an¬ 
nounced the first in a series of new super¬ 
computers built around the Intel I860 mi¬ 
croprocessor. According to the company, 
the IPSC/860 supercomputer provides up 
to 7.6 Gflops of peak performance with 2 
Gbytes of main memory and more than 
100 Gbytes of disk storage. 

The company calls the system mas¬ 
sively parallel, modular, and highly scal¬ 
able. It features from 8-128 processors, 
I/O facilities, and a Direct-Connect com¬ 
munications network, which ties together 
all processors. The IPSC/860 results from 
the Touchstone project, jointly financed 


ment units, and data and instruction 
caches. It incorporates more than 1.2 
million transistors. 

The 040 costs $795 in sample quanti¬ 
ties. It comes in a 179-pin ceramic PGA 
and is compatible with earlier members 
of the 68000 family. 
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by Intel and DARPA. 

Operating system and runtime software 
include a Unix V implementation and a 
kernel operating system, NX/2, on each 
node. 

Five field-upgradable models are 
available, with performance ranging from 
480 Mflops to 7.6 Gflops. RAM ranges 
from 64 Mbytes to 2 Gbytes. The sys¬ 
tems are air cooled and rely on conven¬ 
tional power supplies. 

System prices for the IPSC/860 start at 
$265,000. 
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TI extends 1500 family 
with entry-level model 

Texas Instruments has added the en¬ 
try-level 1505 model to its Unix-based 
1500 family. The new model incorpo¬ 
rates Motorola’s 25-MHz 68030 micro¬ 
processor and supports 8-32 users. The 
communications subsystem and the disk 
controller both reside on the mother¬ 
board. 

The 1505 is object-code compatible 
with other members of the 1500 family. 

It uses the same TI System V operating 
environment. 

The 1505 comes standard with a 25- 
MHz 68882 floating-point coprocessor, 
64 Kbytes of on-board cache memory, 
and 4 Mbytes of RAM expandable to 16 
Mbytes in 4-Mbyte increments. The 
floor-standing system includes one 5.25- 
inch 182-, 380-, or 760-Mbyte SCSI-2 
disk drive and a 150-Mbyte cartridge 
tape backup. Maximum mass storage is 
4.56 Gbytes. 

The 1505 costs $12,900 for the base 
configuration with a 182-Mbyte disk 
drive, a 150-Mbyte tape drive, and 4 
Mbytes of RAM. 
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Intel builds new supercomputer around I860 


Alliant supercomputer combines I860 with PAX standard 


Alliant Computer Systems claims that 
its family of FX/2800 supercomputers 
combines a RISC-based architecture with 
an open technical computing software 
standard. The supercomputers support 
the Parallel Architecture Extended 
(PAX) technical computing standard 
jointly developed by Alliant and Intel. 
PAX-compliant software reportedly runs 
unaltered on any 1860-based computer. 

The FX/2800 incorporates Intel’s 64- 
bit RISC I860 chip. According to the 
company, an adaptive supercomputing 
design allows users to configure the sys¬ 
tems in a variety of ways, working as 
one large cluster of processors or sepa¬ 
rately as independent units. 

The systems use Concentrix and Unix 
System V Release 4 as the operating en¬ 
vironment. They connect to other sys¬ 
tems via Ethernet, DECnet, Ultranet, 
TCP/IP, NFS, NQS, and X Windows. 

Models range from the eight-processor 
FX/2802 to the 28-processor FX/2828. 
Prices range from $500,000 to $2 mil¬ 
lion. Users can add processors within the 
existing cabinet. Moreover, they can up¬ 
grade current FX/Series systems to FX/ 
2800 systems. 
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Alliant’s FX/2800 supercomputer combines Intel’s I860 processor with the PAX 
computing standard. 
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Tape backup goes portable 


Valitek calls its PST the first portable 
tape backup system to operate through 
both parallel and serial ports of IBM- 
compatible PCs. The PST does not re¬ 
quire controller cards. Users can plug the 
cable into the parallel or serial port of a 
PC. 

The PST comes in 60- and 160-Mbyte 
configurations. It reputedly backs up 
hard disk files at rates up to 4.5 Mbytes 
per minute through the parallel port and 
115.2 Kbaud through the serial port. 

The menu-driven software for the PST 
runs from a disk or hard disk drive. It 
provides on-screen tagging of files or di¬ 
rectories, wild-card tagging, and file tag¬ 
ging by date modified, archive, hidden, 
and system file attributes. Users can also 
create batch files. 

The Valitek PST stores data on digital 
data cassettes. No preformatting is re¬ 
quired. 



Valitek’s PST portable tape backup unit stores data on digital data cassettes. 


The PST-60 retails for $ 1,695 and the 
PST-160 for $1,995. Both come with 
software (on both a 3.5-inch and a 5.25- 
inch disk), documentation, cassette, 


M/F DB25 shielded cable, and limited 
warranty. 
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Arix expands Unix-based supermini line 


Arix has added three models to its 
System 90 family of Unix-based super¬ 
minicomputers. Model 90/25 supports 
16-128 users, up to 160 Mbytes of mem¬ 
ory, and more than 5 Gbytes of disk stor¬ 
age. Model 90/45 supports 128-256 us¬ 
ers, up to 416 Mbytes of memory, and 


Intergraph’s new 6000 Series worksta¬ 
tions run under the Clix operating sys¬ 
tem, the company’s implementation of 
AT&T’s Unix System V, Release 3.1, 
with Berkeley extensions. The new sys¬ 
tems also come with the company’s Ex¬ 
tensible Display Geometry Engine 
(EDGE) graphics processor, plus Look¬ 
ing Glass, an icon-based, menu-driven 
user interface from Visix. 

The first level of graphics perform¬ 
ance, EDGE I, supports eight planes and 
one highlight plane of double-buffered 
graphics. EDGE I permits the display 
of 256 colors plus one highlight color 
from a palette of 16.7 million. A digital 
signal processor executes graphics pri¬ 
mitives. 

The second level of graphics perform¬ 
ance, EDGE II, provides 24-bit color and 
allows the display of the full palette of 
16.7 million colors. It reputedly supports 
drawing rates of 400,000 2D vectors per 


more than 63 Gbytes of disk storage. 
Model 90/85 supports 256-512 users, up 
to 416 Mbytes of memory, and more than 
82 Gbytes of disk storage. 

Prices for Model 90/25 and 90/45 start 
at about $52,000 and $128,000, respec¬ 
tively. Model 90/85 prices start around 


second and 350,000 3D vectors per sec¬ 
ond. EDGE II also permits rendering 
with Gouraud shading at 25,000 100- 
pixel shaded triangles per second, ac¬ 
cording to the company. 

The Interpro 6040 workstation in¬ 
cludes a 10-MIPS RISC microprocessor, 
EDGE I graphics, 16 Mbytes of main 
memory, and a 355-Mbyte disk drive for 
a price of $29,900. It supports a total of 
80 Mbytes of main memory and 2.7 
Gbytes of disk storage. 

The Interpro 6280 reportedly offers 14 
MIPS of performance. It comes with 
EDGE II graphics, 16 Mbytes of main 
memory, and 670-Mbyte disk drive for a 
price of $45,900. It is scheduled for 
availability in the second quarter of 
1990. 

A variety of other configurations are 
available. 
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$260,000, with availability in June. 

Arix has also announced Release 3 of 
the OS/90 operating system, based on 
AT&T Unix System V, Release 3.0. The 
company claims that the new release 
complies with Posix 1003.1 and meets 
level C2 security requirements. 
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CDC builds departmental 
computers on RISC, Unix 

Control Data has built its new 4000 se¬ 
ries of departmental computers on re¬ 
duced instruction set computing architec¬ 
ture. The four new binary-compatible 
models run Classix, the company’s ver¬ 
sion of the Unix operating system. 

The high-end Control Data 4680 incor¬ 
porates Mips Computers Systems’ R6000 
RISC CPU chip coupled to a floating¬ 
point processor. According to the com¬ 
pany, multiple independent VME buses 
provide a cumulative 200-Mbps I/O 
bandwidth. The 4680 is scheduled for 
availability in May. 

The midrange and low-end Control 
Data 4380, 4360, and 4340 reportedly 
provide performance of 18 to 20 VAX 
MIPS. They are available now. 

Prices range from $30,000 to 
$152,000. 


Intergraph bases workstations on Unix 
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Company, Model, Function 

Comments R.S. No. 

Analog Devices 

AD9060 

ADC 

An ECL-compatible 10-bit A/D converter with guaranteed encode rates up to 75 million 120 

samples per second. Provides a minimum 56-dB signal-to-noise ratio and 45-pF input capaci¬ 
tance. Comes in a 68-pin ceramic leaded or LCC package in two performance grades over two 
temperature ranges. Cost (100s): starts at $185. 

Burr-Brown 

ADS7800 

ADC 

A 12-bit sampling A/D converter. Acquires a sample in 300 ns max and converts in 2.7 (is max 121 
for a min throughput rate of 333 kHz. Provides input ranges of ±10V or ±5V. Has internal 
sample/hold, reference, clock, digital interface, and three-state output drivers. Comes in a 24- 
pin ceramic DIP in two grades over two temperature ranges. Cost (100s): $23.95. 

Catalyst Semiconductor 
CAT71C245LPI 

SRAM 

A 256-Kbit static RAM organized 32Kx8, with an access time of 85 ns. Guaranteed over the in- 122 
dustrial temperature range. Requires a 5V power supply, 80 mA max when active and 100 p.A 
max when standby. Provides direct TTL I/O compatibility. Cost (1,000s): $19.04. 

Fujitsu 

MB40xx 

Data acquisition ICs 

A family of five general-purpose data acquisition ICs composed of 4-, 6-, and 8-channel ana- 123 

log multiplexers, A/D converters, and associated timing and control logic functions on one IC. 

MB4051 comes in a 42-pin plastic or ceramic DIP; MB4052, -53, and -63, in 16-pin DIP and 

SOJ packages; and MB4056 in a 20-pin plastic DIP. Cost (1,000s): from $2.32-$20.07. 

Hyundai 

HY51C1000/L 

DRAM 

A fast page mode dynamic RAM organized lMxl bit. Provides a sustained data rate over 16 124 

MHz. TTL-compatible I/O. Available in 100-ns and 120-ns versions. Max current of 70 mA at 

120 ns, 75 mA at 100 ns. Comes in an 18-pin 300-mil DIP. No prices given. 

Intel 

82340 (SX or DX) 

Chip set 

A 16-bit chip set that supports the 32-bit 386 microprocessor architecture, from the 386SX 125 

(82340SX, consisting of two chips) to the 33-MHz 386DX (82340DX, consisting of three 
chips). Produced by VLSI Technology under the Topcat name. Cost (1,000s): $50 for 

82340SX; $75 for 82340DX. 

Lattice Semiconductor 
GAL22V10 

PLD family 

A family of reprogrammable logic devices based on the 22V10 architecture. GAL18V10 and 126 
GAL26CV12 operate at 62.5 MHz with a 15-ns max propagation delay. GAL18V10 comes in a 

20-pin plastic DIP and has eight dedicated input pins and 10 I/O pins. GAL26CV12 comes in a 

28-pin plastic DIP and has 14 dedicated inputs and 12 I/O pins. Cost (100s): $12.33 for 

GAL18V10; $24.64 for GAL26CV12. 

LSI Logic 

L64290 

Object contour tracer 

An image processing device. Receives input as a binary image (one bit per pixel). Outputs co- 127 
ordinates of contours, including a slope and curvature sequence. Also computes a bounding 
box. Comes in a 68-lead ceramic PGA in two speeds. Cost (100s): $295 for 15-MHz 

L64290GC-15; $385 for 20-MHz L64290GC-20. 

LSI Logic 

L64212GC-40 

Video shift register 

A variable-length DSP video shift register with a clock rate of 40 MHz. Consists of four 9-bit 128 

wide shift registers, each programmable to any length between 11 and 1,035 words. Uses a 
static RAM implementation. Comes in a 95-lead ceramic PGA. Cost (100s): $227.60 ($175 for 

30-MHz L64212GC-30). 

Precision Monolithics 
SSM-2131 

Audio op amp 

An operational amplifier with a total harmonic distortion of 0.01 percent, a 50V/mS typical 129 

slew rate, and a 10-MHz bandwidth. Operates over the extended temperature range. Comes in 
an 8-pin plastic DIP or SO-8 package. Cost (100s): $1.95. 

SGS-Thomson 

TS75C25 

Modem chip set 

A two-chip V.22 bis modem that consumes less than 0.7W of power. Consists of a prepro- 130 

grammed DSP (TS75C250) and an analog front end (TS7542). Operates at up to 2,400 bps in 
full duplex mode. Supports CCITT V.21, V.22, V.23, Bell 103 and 212. Cost (10,000s): $20. 

Sipex 

SP1072B 

ADC 

A dual A/D converter with Mil-Std-883C screening. Has two 25-MHz flash converters with 131 

three-state outputs, an on-board voltage reference, and two 11-MHz full-power bandwidth 
buffer amps. Comes in a 42-pin hermetic package with power consumption of 2.6W. Cost 
(100s): $580. 

Sony 

CXA1236Q 

Video DAC 

An 8-bit, 500-MHz, single video D/A converter with functions for composite sync, blank, ref- 132 
erence white, enhanced white/black, and bright control inputs. Has power dissipation of 935 
mW. Handles 25 ohms/37.5 ohms loading. Comes in a 44-pin ceramic quad flat pack. Cost 
(100s): $94. 
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Microsystem Announcements 


Company, Model, Function _ Comments _ R S. No. 

Acropolis Systems A plug-in memory board for laptop and dim-top models of Sun-3/50 workstations. Exploits the 135 

ASI16X staggering precharge design technique. Accesses 4 Mbytes at a time, keeping power consump- 

Memory board tion low. Requires no soldering. Cost: $495 (OK) to $1,575 (12 Mbytes). 

Antex Electronics A full-length digital audio board for IBM PC ATs, PS/2 Model 30s, and compatible 286/386 136 

Series 2/Model SX-10 computers. Built around TI’s 25-MHz TMS320C10 DSP chip. Receives both analog and digi- 

Digital audio board tal audio signals. Can digitize two audio channels. Cost: $1,995; $750 for optional driver. 

Behavior Tech Computer A workstation based on Intel’s 25-MHz 80486 CPU. Has a second-level cache option and 137 

StarFlex SF-4025 Weitek 4167 coprocessor support with an adapter board. Desktop or tower configuration with 

Workstation 1-4 Mbytes of 80-ns SIMM and 64 Kbytes of cache memory. Comes with a 1.2-Mbyte floppy 

drive. Cost: starts at $5,260. 


Keithley MetraByte A single-channel, VGA graphics overlay and frame grabber interface board for IBM PC AT or 138 

MV-Spectrum compatible computers. Features a 30-Hz frame rate, RSI70 and NTSC compatibility, pro- 

Frame grabber grammable high-resolution modes, and the ability to display multiple images on a single moni¬ 

tor. Comes with C callable subroutines and Grabtest software. Cost: $2,495. 


S-series 

Modems 


A series of LPDA-2 compatible network management modems for leased lines, including 139 

9,600 and 14,400 bps point-to-point modems and multipoint units. Implement LPDA-2 signal¬ 
ing in native mode. Has SNA compatibility at the protocol level. Cost: starts at $2,995. 


PC/Alibi A fax/modem half card for Toshiba laptops. Transmits data at 4,800/9,600 bps to Group III 140 

Send Fax/Modem faxes. Has a pop-up menu, telephone directory, delayed broadcasting, and auto calling log. 

Fax/modem card Changing disks switches to a 2,400/4,800-baud, Hayes-compatible modem. Cost: $199. 


PC/M A multiprocessor board for DSP operations in the VMEbus environment. Available as an inte- 141 

DSP-2 grated component in the Hyperflo system. Provides three TMS320C30 DSP devices con- 

Multiprocessor board nected through FIFO channels. Comes with DSP programming tools and library. An on-board 

68030 processor automatically manages the system under control of the FLOS operating sys¬ 
tem. Cost: $11,448. 


Pioneer Computer 
Vantage Cache 386-33 
Motherboard 


Siemens Information 
Systems 
CPU 486 
80486 board 


A 33-MHz 80386 motherboard with 64-Kbyte zero-wait-state static cache memory. Holds up 142 
to 8 Mbytes of on-board memory, expandable to 16 Mbytes with a 32-bit memory expansion 
board. Supports DOS, OS/2, Windows 386, Desqview, Unix, Xenix, and Novell operating sys¬ 
tems. Cost: starts at $1,235 (0 Kbytes of memory). 

A CPU board based on Intel’s 25-MHz 80486 microprocessor. Uses the slot-CPU concept, 143 
which puts the processor, memory, serial and parallel ports, and disk controllers onto one 
board. Has 1 Mbyte of RAM expandable to 32 Mbytes, 8 Kbytes of cache memory, and support 
for DOS, OS/2, and Unix. Video controllers are added on a piggyback board. No prices given. 


Spectrum Signal 
Processing 
DSP32C 
Processor board 

Vocal Technologies 
Stowaway 9624 
Fax/data modem 


WinSystems 

MCM-386SX 

SBC 


Zenith Data Systems 

Z-386/33E 

PC 


Based on AT&T’s 32-bit floating-signal processor, the DSP32C. Features a prototyping area 144 
of about one-third of the board. Comes with 32 Kbytes of zero-wait-state nonexpandable 
RAM, 128 Kbytes of two-wait-state expandable RAM, 64 Kbytes of memory, interface func¬ 
tion library, monitor software, and DSP-Link interface. Cost: $1,995. 

A portable fax/modem measuring 4.2x2.2x0.8 inches and weighing 5 ounces (with internal 9V 145 
battery). Hayes compatible, with auto dial/answer, tone and pulse dialing, 40-character com¬ 
mand buffer, nonvolatile memory, status lights, and fax support software. Provides Group III 
compatibility at 9,600 baud with auto fallback capability. Cost: $645. 

An IBM PC AT-compatible single-board computer based on the 16-MHz Intel 80386SX CPU, 146 
Chips and Technologies TREAT chip set, and Phoenix BIOS. Has 512 Kbytes to 4 Mbytes of 
DRAM, 256 Kbytes of EPROM, 15 interrupt channels, two RS-232 channels, a parallel I/O 
port, a real-time clock, and two DMA channels. Cost: starts at $1,795. 

An EISA PC built around Intel’s 33-MHz 80386 CPU. Features the EISA Mass-Storage Con- 147 
troller, with two processors and 1 Mbyte of cache memory. Has 4 Mbytes of cached system 
memory, four open EISA slots, VGA card, DOS 3.3 Plus, and Windows 386. Cost: $11,999 for 
Model 150 (150-Mbyte hard drive); $13,799 for Model 320 (320-Mbyte hard drive). 
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W ell into its third decade, the engineering of software is becoming the engineering of 
computerized applications. Increasingly, new systems arise through the adaptation and 
integration of existing applications, with software as the glue that holds the pieces together 
(in much the same way that CAD and CAM have been integrated as Computer Integrated 
Engineering). Creating these systems requires the expertise and cooperation of a wide array of 
specialists — specialists in the application domain, in real time performance, and in reliability. The 
software engineer becomes a system designer who must understand the application domain in order 
to select not only the system’s software but also its hardware. Perhaps most importantly, the system 
designer must be able to work well in teams with others. 

These complexities are giving rise to new, often interdisciplinary software engineering research 
subjects. Already, a wealth of experience and insight has emerged from research in such disciplines as 
computer supported cooperative work, distributed systems design, reverse engineering, integration 
technology, and computer aided education and training. And the more established research subjects 
— quantitative methods, languages and representations, project management, and others — are 
expanding in breadth and excitement. From this work, a new generation of tools and techniques for 
improving the precision, quality, and predictability of system building projects is arising. Without 
superb technology and continued research, companies and nations will lack the productivity to be 
competitive. 

ICSE invites researchers and practitioners to share their recent ideas and experiences, particularly those 
which aim to improve the design of complex computer applications. The program committee will 
review all submissions for quality and for relevance to future work. Papers, panel proposals, and 
reports must be received in writing by September 14, 1990. 

SUBMISSIONS: Eight (8) copies in English of papers, panel proposals, or experience reports should be 
submitted to the address below by September 14, 1990: 

David Barstow 

Schlumberger Laboratory for Computer Science 
P.O. Box 200015 
Austin, Texas 78720-0015 

Papers should be limited to 6000 words, full-page figures being counted as 300 words. Each paper 
must include a short abstract, a list of keywords, and the lead author’s address. 

Panel proposals should include title, proposed chair, tentative panelists (including a short vita), a two 
or three paragraph description of the subject, format of the presentation, and rationale for the panel. 


TUTORIAL CHAIR: 

Herb Krasner 
Lockheed 

Software Technology Center 

09610/B30E 

2100 East St. Elmo 

Austin, Texas 78744 USA 

krasner@stc. lockheed .com 

512/448-5738 

FAX: 512/448-5728 

LOCAL ARRANGEMENTS 
CHAIR: 

Bryan Fugate 

ICSE 13 Local Arrangements 
MCC 

P.O. Box 200195 
Austin, Texas 78759 USA 
fugate@mcc.com 
512/338-3330 
FAX: 512/338-3899 


Experience reports should describe practical experience in some aspect of software engineering (using 
a tool or method, applying a metric, following a project management discipline, reusing work 
products, etc.). The contributor(s) should submit a 5 to 10-page written description of the experience 
and a one-page outline for a five-minute presentation. 

TOOLS FAIR: A software tools fair will be held during the conference, so that attendees can see and learn 
about current experimental and commercial software tools. Those who want to exhibit or demonstrate a 
tool, and especially those interested in presenting a descriptive paper, should contact: 

Laurie or John Werth 
Department of Computer Science 
University of Texas at Austin 
Austin, Texas 78712 

FURTHER INFORMATION: For further information and/or copy of the advance program when available, 
write either to ICSE13, MCC, P. O. Box 200195, Austin, Texas 78720 USA, or to ICSE 13, IEEE 
Computer Society, 1730 Massachusetts Ave., NW, Washington, DC, 20036 USA. 

IMPORTANT DATES: Submission deadline: 14 September 1990; Acceptance notification: 14 December 
1990; Final versions due: 8 February 1991. 



Sponsored by ACM Special Interest Group on Software Engineering 
IEEE Computer Society Technical Committee on Software Engineering 
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CI 90 will focus on the expanding scope and requirements of expert systems: more and more of these have to cooperate 
well with other software modules such as databases, numerical processing, signal processing, etc. as well as various kind of 
users environments. For instance, what are the problems and requirements for combining the use of ‘subsymbolic’ com¬ 
puting in neural nets or complex dynamic systems in general with conventional ‘symbolic’ processing? 

Topic areas include, but are not limited to: 

• Interaction between real-time systems and expert systems. 

• Problems of expert systems that involve pattern recognition, signal processing and the integration of new techni¬ 
ques emerging from neural networks. 

• Use of new interfaces, such as hypermedia, for expert systems, multimodal user interfaces. 

• What are the ways in which expert systems technology impacts current data base design. 

• When and how should semantic and neural nets be combined. 

• Deep knowledge systems derived from qualitative models and their integration with knowledge bases. 

• Case-based expert systems and their integration with learning algorithms of different nature (statistics, Al-based, 
neural-nets, etc.). 

• General principles and methodology for heterogeneous knowledge integration. 

Submit five copies of paper (in English, not to exceed 20 double-spaced pages) to either Program Chairs. Papers will be ac¬ 
cepted for evaluation until April 20,1990. Each paper should have a cover page which includes: paper title and full names, 
affiliations, complete addresses, phone, fax, e.mail and telex numbers of the authors. 

Submission by electronic mail is encouraged as long as the author sends the additional material (e.g. figures) in time. 
Notification of selection will be given by June 8, 1990. Authors of accepted papers will be requested to submit a final 
camera-ready copy by July 30,1990. Send proposal for full or 1/2 day tutorials to the Tutorial Chair. Tutorial proposals 
must be received by April 30, 1990. Proposals should include: speakers resume, tutorial title, intended audience, assumed 
attendee background, course description, outline, and a sample of several overhead/slides to be used. 

Research in progress session. A special session is held on Thursday 27 September for presentation of a brief overview of 
new work not yet ready for formal publication. A one page abstract must be submitted by August 31st to Publication 
Chair. Student contest: it will be held on September 24. Send proposals before June 30th to Chair. 
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Cadiou, Liskov, Squires to address ICSE 12 plenary sessions in France 


Jean-Marie Cadiou of CEC/Esprit, 
Barbara Liskov of the Massachusetts In¬ 
stitute of Technology, and Steve Squires 
of DARPA will be the plenary speakers 
when the 12th International Conference 
on Software Engineering convenes in 
Nice, France, March 26-30. 

Francois-Regis Valette of ONERA- 
CERT is general chair of ICSE 12, with 
Peter Freeman of George Mason Univer¬ 
sity and the University of California at 
Irvine and Marie-Claude Gaudel of 
Universite de Paris — Sud serving as the 
program co-chairs. 

The IEEE Computer Society Technical 
Committee on Software Engineering, 
ACM Special Interest Group on Software 
Engineering, and AFCET (Association 
Francaise pour la Cybemetique Econ- 
omique et Technique) are sponsoring the 
event, to be held at the Nice Acropolis 
Convention Center. 

Valette said that ICSE 12’s theme is 


“Building a Foundation for the Future.” 
The agenda will present “a well-balanced 
selection of research results, experience, 
and workshop reports, surveys, panels, 
and forward-looking plenary addresses 
that together reflect a focus on fundamen¬ 
tals that will be useful for the future.” 

Cadiou, Liskov, and Squires will speak 
March 28, 29, and 30, respectively. 
Cadiou will present an overview and re¬ 
port on European Community programs 
designed to lay the foundation for the fu¬ 
ture of software engineering in the mem¬ 
ber countries. 

Liskov will report on her recent re¬ 
search on the development of distributed 
systems. 

Squires will discuss the new chal¬ 
lenges and problems introduced in devel¬ 
oping software for high-performance 
computers (with massive parallelism). 

The technical program will feature 30 
invited papers; four panel discussions ex¬ 


ploring such topics as software reengi¬ 
neering, safety-critical software, and the 
types of models used to guide technology 
transfer; and four special sessions on re¬ 
cent advances in fundamental areas. The 
latter aspect, new for this year’s ICSE, 
will feature Victor Basili of the Univer¬ 
sity of Maryland as the invited speaker on 
metrics and Francois Bancilhon of GIP 
Aitair discussing object-management 
systems. 

Four day-long tutorials will be pre¬ 
sented each of the first two days of ICSE 
12, and a tools fair the final three days will 
be devoted to expanding technical under¬ 
standing of demonstrated tools. 

For further information, contact the 
IEEE Computer Society, 1730 Massa¬ 
chusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013, or 
ICSE 12, AFCET, 156 boulevard Pereire, 
75017 Paris, France, phone 33 (14) 47- 
66-24-19. 


Digital font technology key topic at Swiss RIDT workshop 

R.D. Hersch, Ecole Polytechnique Federate 
Debra Adams, Xerox PARC 


Digital font technology was the princi¬ 
pal topic when the International Work¬ 
shop on Raster Imaging and Digital Ty¬ 
pography was held at the Ecole Polytech¬ 
nique Federale in Lausanne (EPFL), 
Switzerland. In addition to computer sci¬ 
entists, attendees at RIDT 89 October 12 
and 13 included representatives of the 
font design, font production, and digital 
typography fields. 

In a dozen talks on digital font technol¬ 
ogy, methods were discussed for render¬ 
ing character outlines, and various font 
scaling techniques (also known as font 
hinting) were presented. 

Problems of font quality were fre¬ 
quently debated. What kind of hinting 
technique produces the highest quality 
fonts? Should type designers be able to 
set hints by themselves or should they be 
relieved of such tasks by automatic pro¬ 


grams? What does the term “font quality” 
mean and how do we conduct font quality 
assessments? 

Besides issues related to font creation, 
generation, and output quality, speakers 
presented several other high-interest 
subjects related to typography. A type 
designer discussed an investigation of 
variations one has go through to produce 
high-quality bitmap characters. Another 
speaker presented a historically oriented 
talk about the evolution of digitized He¬ 
brew fonts. A complete session was de¬ 
voted to Kanji font generation and scan 
conversion. The speakers developed 
methods to rasterize the highly complex 
Kanji ideograms on middle-resolution 
printers and screens. 

Dynamic fonts. Of the broad spectrum 
of topics at the conference, one that may 


be a harbinger of advances in font tech¬ 
nology deals with a rather revolutionary 
way of considering fonts. It was pre¬ 
sented in a paper entitled “Dynamic 
Fonts” by Jacques Andre and Bruno Bor- 
ghi of INRIA/IRISA in France. In these 
fonts, the instantiation of each character 
is unique and defined at print time. For 
example, the width of a lowercase “m” in 
a dynamic font might expand or contract 
each time it is rendered. This differs from 
traditional typeface design and font pro¬ 
duction, in which an entire font of charac¬ 
ter shapes is predefined and fixed prior to 
its use in printing. 

It also differs from the typical use of 
Knuth’s Nfletafont language to predefine 
a set of parametric variations applied to a 
metafont definition. In the latter case, the 
shape of a given character may vary from 
font to font, but within a single font, its 
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shape is static. Sets of handwritten char¬ 
acters are good examples of dynamic 
fonts. 

Andre and Borghi discussed three 
classes of dynamic fonts in their paper. 
The classes are distinguished by the 
amount and type of information ex¬ 
changed with the font-rendering machin¬ 
ery. In the first class, dynamic fonts are 
generated by random functions that de¬ 
termine the amount and kinds of charac¬ 
ter shape deformation that will occur as 
each character is created. For example, 
each instance of a character shape can be 
randomly rotated at a new angle. No in¬ 
formation is exchanged with the font ma¬ 
chinery to achieve this; random dynamic 
fonts are self-sufficient. 

In the second class, characters in a dy¬ 
namic font are modified depending on a 
limited set of read-only parameter values 
supplied to the font machinery. To justify 
lines of characters in Semitic texts, for 
example, character shapes are altered to 
fill the line rather than modifying inter- 
character spacing. Here, the width value 
of a character shape depends on the ex¬ 
pected amount of line justification. Com¬ 
puted width values are sent to the font 
machinery and the shape is modified. 

In the third class of dynamic fonts, 
character changes are more thoroughly 
dependent on the context (that is, a large 
number of variables), and conversely, the 
context may be modified by the charac¬ 
ters in the font. There is a two-way ex¬ 
change of information. Specifically, ty¬ 
pographic parameters used to compose a 
page, such as the page margins or inter- 


Weizmann to be opening 

Ezer Weizmann, Israel’s Minister of 
Science and Technology, will deliver the 
opening address May 8 at the 1990 IEEE 
International Conference on Computer 
Systems and Software Engineering in Tel 
Aviv, Israel. 

Josef Raviv of the IBM Scientific Cen¬ 
ter in Israel is CompEuro 90 conference 
chair, with Jonah Z. Lavi of the Embed¬ 
ded Computer Systems Division of Israel 
Aircraft Industries and Walter E. Proeb- 
ster of IBM in West Germany the techni¬ 
cal program co-chairs. 

The May 8-10 event at the Tel Aviv Hil¬ 
ton is sponsored by the IEEE Computer 
Society, the IEEE’s Region 8 and Israel 
Section, and the Information Processing 
Association of Israel. 

Michael Rabin of the Hebrew Univer- 


line spacing, may be set in relation to par¬ 
ticular characteristics of a given typeface 
design and, in turn, the characters may be 
varied depending on the typographic 
parameters. The concept of context-de¬ 
pendent character modification is rele¬ 
vant for gray scale character rendering 
and automatic character kerning, as well 
as other inventive applications. 

The authors used Postscript to produce 
dynamic fonts because, with Postscript, 
bitmap characters are generated from 
modified outline character shapes just 
prior to printing. This facility is not sup¬ 
ported in systems such as Metafont. 

Although the notion of dynamic fonts 
may not be directly useful for traditional 
typographic purposes, it deserves men¬ 
tion as an experimental approach to dy¬ 
namic typography. One goal of this re¬ 
search is to question conventions that 
may have become too fixed over time. A 
dynamic font has recently been devel¬ 
oped by Christan Delorme, a French type 
designer. 

Outlook for the 90s. There was gen¬ 
eral agreement at the conference that the 
1990s will bring more automatic typogra¬ 
phy tools and reduce the need for tedious 
interactive work. In this context, several 
participants requested undertaking re¬ 
search and development of models of 
human perception. Such models could be 
incorporated into advanced tools able to 
make correct decisions about the place¬ 
ment of font scaling hints, outline defor¬ 
mation, and character uniformity. 

Issues related to antialiased character 


sity of Jerusalem and Harvard University 
will deliver on opening-session lecture 
on “How to Use Parallelism If You 
Must,” followed by plenary-session talks 
by D. Frohman of Intel, Israel, on “VLSI 
Technology: Outlook and Impact on Sys¬ 
tems of the Year 2000”; H.G. Sol of the 
Delft University of Technology in the 
Netherlands on “System Engineering Is¬ 
sues”; and M. Jackson of Systems, Ltd., 
in the UK on “Complexities in Computer- 
Based Systems.” 

Systems Engineering Aspects of Com¬ 
plex Computerized Systems is the theme 
of the event, which will feature 70 papers 
and two poster sessions during 26 techni¬ 
cal presentations the first two days. The 
papers will focus on systems engineering 
aspects of complex computer-based sys- 


generation, automatic hinting, nonlinear 
character deformation for the compensa¬ 
tion of printer effects and high quality 
device-independent color reproduction 
were targeted as current hot research top- 

A few papers at RIDT 89 were dedi¬ 
cated to problems of raster imaging hav¬ 
ing no direct relation to fonts. New 
antialiasing algorithms, comparisons of 
hexagonal and square grid-based images, 
and new image descriptions based on 
polygonal segmentation of color raster 
images were presented. 

The talks were complemented by dem¬ 
onstrations showing the latest font soft¬ 
ware packages from Adobe, Bitstream, 
and URW, as well as recent work devel¬ 
oped at universities (Typo font editor, 
Jerusalem; Font editor and object- 
oriented document manipulation, ETHZ; 
and intelligent rasterization software, 
EPFL). 

The next RIDT workshop will be held 
in Boston, most likely in mid-1991. 

A related conference and exhibition, 
called Electronic Publishing 90, will be 
held September 18-20 at the National In¬ 
stitute for Standards and Technology in 
Gaithersburg, Maryland. Sponsored by 
NIST with IEEE Computer Society coop¬ 
eration, EP 90 will be the third in a series 
of international conferences established 
to bring together researchers in the areas 
of electronic publishing, document 
manipulation, and typography. For infor¬ 
mation, contact Lawrence A. Welsch, 
Bldg. 225, Rm. B252, NIST, Gaithers¬ 
burg, MD 20899. 


in Israel 

terns and their software, reports on expe¬ 
rience with development-environment 
architecture, knowledge-based systems, 
rapid prototyping, systems and software 
engineering tools, software validation 
and verification, and case studies. 

Panel discussions will be devoted to 
object-oriented systems development 
and basic issues underlying computer 
systems engineering as an emerging dis¬ 
cipline. Three all-day tutorials will be 
presented the final day. 

Discounts are available on registration 
and tutorial attendance fees reaching the 
secretariat before March 31. To obtain 
discounts or further information, contact 
the CompEuro 90 Secretariat, PO Box 
50432, Tel Aviv 61500, Israel, phone 972 
(3) 3-664825, fax 972 (3) 660952. 


speaker at CompEuro 90 
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Bug-free chip design explored 
at Belgium workshop 

Luc Claesen, Interuniversity Micro Electronics Center 

Focusing on novel techniques to correctly design ICs, Randal 
E. Bryant and Warren Hunt, Jr., presented invited addresses at 
the IMEC-IFIP International Workshop on Applied Formal 
Methods for Correct VLSI Design. The forum was organized by 
Belgium’s Interuniversity Micro Electronics Center of Leuven, 
in cooperation with Working Groups 10.2 and 10.5 of the Inter¬ 
national Federation for Information Processing. It was held in 
Leuven November 12-16, with Luc Claesen of IMEC serving as 
general chair. 

Bryant of Carnegie Mellon University devoted his remarks to 
“Symbolic Analysis and Verification of MOS Circuits,” and 
Hunt of the University of Texas and CLI spoke on “The Formal 
Design and Verification of Hardware Based on the Boyer- 
Moore Prover.” 

Functional and behavioral verification of correctness is the 
bottleneck in current VLSI design systems. For the sake of econ¬ 
omy, VLSI circuit design must be completely validated before 
manufacturing begins. Current VLSI validation is mainly done 
through extensive simulation. The emerging alternative is 
based on formal design and verification methods that guarantee 
correctness. 

Applied methods were emphasized at the regular workshop 
presentations and the poster session, with demonstrations of 
realistic design problems and solutions. These have substantial 
potential for future applications to large VLSI designs. 

A number of papers addressed “guided synthesis” methods. 
These complement current research in automatic synthesis for 
applications still needing considerable designer ingenuity be¬ 
cause no automatic coping methods exist. 

In this context, David Knapp of the University of Illinois pre¬ 
sented a formalization of the correctness in linked representa¬ 
tions of datapath hardware. The concepts were illustrated 
through demonstration of interactive changes and design trans¬ 
formations on a 6502 microprocessor design. Simon Finn and 
Mike Forman of Abstract Hardware Ltd. presented a demonstra¬ 
tion on the Lambda system, which provides a designer-oriented 
schematics interface to a higher order logic-based theorem 
prover to gradually transform a design from specification into 
implementation in a highly interactive fashion. 

Progress was demonstrated in the automatic verification be¬ 
tween register-transfer-level specifications and gate-level 
implementations. Hans Eveking of Technische Hochshule 
Darmstadt presented and demonstrated Lovert, a verifier for 
register-transfer-level descriptions. Lovert confirms the cor¬ 
rect implementation of a Boolean function. It does so by means 
of gates as well as the correct aggregation of scalar Boolean ex¬ 
pressions to vector expressions and the correct implementation 
of transfer-like events such as microprogram instructions by 
means of structural resources like ALUs and buses. 

A set of benchmarks for formal verification and design be¬ 
tween RTL specification and hardware implementation was 
made available to interested participants to facilitate comparing 
and illustrating specific aspects of formal design systems. Sev¬ 
eral papers related and illustrated work on the distributed Min- 
Max benchmark design. A second class of applications con¬ 
sisted of a number of benchmarks for tautology checkers that are 
often available in formal verification systems. In the session 
that Bryant chaired on tautology checking benchmarks, eight 
programs were compared for their basic algorithms, perform¬ 
ance, and efficiency on the same applications. Based on shared- 
binary-decision diagrams, the program by Nagisa Ishiura of 
Kyoto University turned out to be the most efficient. 


April 25-27,1990 - Cambridge, MA 
Kresge Auditorium, MIT 

COIS90 

Conference on Office Information Systems 
Sponsored by ACM SIGOIS and IEEECS TC-OA 
In cooperation with IFIP WG 8.4 
with corporate support from Bellcore and Lotus 
General Chair: Bob Allen, Bellcore 
Program Chair: Fred Lochovsky, U. Toronto, Canada 
Keynote Speaker: Mitchell Kapor, ON Technologies 
SESSIONS/PANELS 

• Distributed OISs 

• Filtering, Querying, and Navigating 

• Organizational Implications 

• Coordination Technology 

• Communication Tools 

• Organizational Data Models 

• Computer Mediated Work Environments 

• Information Access 

• Video Workspaces 

• Evaluating Computer-Based Tools in Organizations 

TUTORIALS, APRIL 24 

• Hypertext/Hypermedia: Jakob Nielsen 

• User Interfaces: Deborah Mayhew 

• Object-Oriented Systems: Clarence Ellis 

• Cooperative Work: Marilyn Mantei 


COIS90 Registration Form (April 25-27, MIT) 

Name _ 

Address _ 


Affiliation_ 

Phone _ 

Electronic Address _ 

Advance After April 9 

_ACM,_IEEECS,_IFIP $225 _ACM,_IEEECS,_IFIP $270 

_Non-members $280 _Non-members $340 

_Students $70 

_One day $120 

_Dinner Buffet at Computer Museum $30. 

TUTORIALS, APRIL 24 (Lunch included if signing up for 2 sessions) 

9:00am _D. Mayhew _J. Nielsen 

1:30pm _M. Mantei _C. Ellis 

Advance (per course) After April 9 

_ACM,_EEEECS,__IFIP $100 _ACM,_IEEECS,_IFIP $125 

_Non-members $125 _Non-members $150 

Total$_ 

Please make check payable to COIS90, and send with this form to: 
Selma M. Kaufman, COIS90, Room 2M-356, Bellcore, Morristown, NJ 
07960-1910. Remittance in U.S. dollars please. For more information, 
phone: (201)829-4280, smk@flash.bellcore.com Conference Hotel: 
Hyatt Regency, Cambridge, MA. phone: (617)491-1234. 
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CALL FOR PAPERS 


Call for papers and referees for Computer 


Computer seeks articles for inclusion in an upcoming 
special issue. 

Experimental Research in Computer Architectures has 

been selected as the theme for the January 1991 edition. If we 
are to implement computing machines that effectively use 
available hardware and software technologies, we must first 
understand system bottlenecks that prevent us from doing so 
and then eliminate them. Since computer design is driven by 
the marketplace, rather than by a desire for internal elegance, 
the successful computer system often contains kludges that 
provide performance advances over its competition. The re¬ 
sult is that, while analytic treatments may be helpful, under¬ 
standing most computer systems requires the use of experi¬ 
mental techniques. 

The purpose of this special issue is to focus on the place of 
experimental research in computer architecture and perform¬ 
ance measurement. We invite papers from hardware design¬ 
ers, system builders, and performance-measurement experi¬ 
menters that deal with experimental methodology, trace- 
driven simulation, and hardware, software, and microcoded 
instrumentation of both commercial machines and engineer¬ 
ing prototypes. We expect this issue to explore the advan¬ 
tages and disadvantages of experimental work and identify 
some of the problems that can attend the misuse of experi¬ 
mental methodology. 


Submitted papers must not have been previously pub¬ 
lished or currently submitted for publication elsewhere. Each 
manuscript should be no more than 32 typewritten, double¬ 
spaced pages in length, including ail figures and references. 
Each submittal should have a cover page that includes the 
title of the paper, full name of the author(s), affiliation(s), 
complete physical and electronic address(es), telephone 
number(s), and a list of keywords identifying the central is¬ 
sues of the manuscript's contents. References should be 
limited to 12 in number. 

Submittals and questions should be directed to the guest 
editor, Yale N. Patt, Department of Electrical Engineering 
and Computer Science, University of Michigan, Ann Arbor, 

Ml 48109-2122, phone (313) 936-1602, electronic mail 
patt@eecs.umich.edu. 

A 300-word abstract should be sent to Patt by April 20, 
1990, and eight copies of the full manuscript must be submit¬ 
ted to him by June 1,1990. Authors will be notified of accep¬ 
tance by August 15,1990. The final version of the manu¬ 
script is due no later than October 1,1990. 

If you are interested in serving as a referee for this special 
issue, send a note indicating your technical interests and 
qualifications to Patt at the above address or to Bruce 
Shriver, Editor-in-Chief, Computer, c/o the University of 
Southwestern Louisiana, Drawer 42730, Lafayette, LA 
70504, e-mail shriver@usl.edu. 


10th Int’l Conf. in Computer Science: July 
23-27, 1990, Santiago, Chile. Submit 10 copies 
of extended abstract by Mar. 20, 1990, to 
Joachim von zur Gathen, Computer Science 
Dept., Univ. of Toronto, 10 King’s College 
Rd., Toronto, Canada M5S 1A4, phone (416) 
978-6024, e-mail gathen@theory.toron 
to.edu. 

ICCC 90,10th Int’l Conf. on Computer 
Communication: Nov. 5-9, 1990, New Delhi, 
India. Sponsor: Int’l Council on Computer 
Communication. Submit paper by Mar. 20, 
1990, to Saroj Chowla, ICCC 90 Secretariat, 
CMC Ltd., A-5 Ring Rd., South Extension Part 
I, New Delhi 110 049, India, phone 91 (11) 626- 
807, fax 91 (11)684-4652. 

1990 Int’l Electronics Packaging Conf.: 

Sept. 9-13, 1990, Marlborough, Mass. Spon¬ 
sor: Int’l Electronics Packaging Society. Sub¬ 
mit eight copies of abstract by Mar. 30, 1990, 
to IEPS Program Committee, 114 N. Hale St., 
Wheaton, IL 60187, phone (708) 260-1044. 

Int’l J. Intelligent Systems plans a special vol¬ 
ume on knowledge acquisition. Submit three 
copies of paper by Mar. 30,1990, to Kenneth 
M. Ford, Inst, for Human and Machine Cogni¬ 


tion, Computer Science Div., Univ. of West 
Florida, Pensacola, FL 32514, phone (904) 
474-2551. 

Int’l Workshop on Principles of Diagnosis: 

July 23-25, 1990, Menlo Park, Calif. Cospon¬ 
sors: American Assoc, for Artificial Intelli¬ 
gence, Price Waterhouse. Submit four copies 
of paper by Mar. 30, 1990, to Walter Ham- 
scher, Price Waterhouse Technology Center, 
68 Willow Rd., Menlo Park, CA 94025, phone 
(415) 688-6669, e-mail hamscher@pw.com. 

J. Internetworking: Research and Experi¬ 
ence seeks original research papers for its sec¬ 
ond issue. Submit full paper or short technical 
note by Mar. 31, 1990, to Deborah L. Estrin, 
Computer Science Dept., Univ. of Southern 
California, Los Angeles, CA 90089-0782, 
phone (213) 743-7842, e-mail estrin@ 
cse.usc.edu. 

AAECC 8, Eighth Int’l Conf. on Applied Al¬ 
gebra, Algebraic Algorithms, and Error- 
Correcting Codes: Aug. 20-24, 1990, Tokyo. 
Submit paper by Mar. 31, 1990, to Hideki 
Imai, Faculty of Engineering, Yokohama Nat’l 
Univ., Tokiwadai, Hodogaya-ku, Yokohama 
240, Japan. 


IEEE Expert is planning a series of ar- 
tides on object-oriented programming 
in artificial intelligence. Submit four copies of 
full manuscript by Apr. 1,1990, to Sherman 
Alpert, PO Box 704, Yorktown Heights, NY 
10598, phone (914) 789-7736, fax (914) 789- 
7279, e-mail alpert@ibm.com. 

CTjl Int’l Symp. on Fuzzy Approach to Rea- 
soning and Decision Making: June 25- 
29, 1990, Bechyne, Czechoslovakia. Cospon¬ 
sor: Int’l Fuzzy System Assoc. Submit paper 
by Apr. 1,1990, to Milan Mares, UTIA- 
CSAV, Pod Vodarenskou Vezi 4, 182 08 Praha 
8, Czechoslovakia. 

IEEE Conf. on Managing Expert Sys- 
tern Programs and Projects: Sept. 10- 
12, 1990, Washington, DC. Sponsor: IEEE 
Computer Society Technical Committee on 
Expert Systems. Submit five copies of paper by 
Apr. 1, 1990, to Randall Shumaker, Navy Cen¬ 
ter for Applied Research in AI, Code 5510, Na¬ 
val Research Lab, Washington, DC 20375. 

Ninth Symp. on Reliable Distributed 

NA7 Systems: Oct. 9-11, 1990, Huntsville, 
Ala. Submit five copies of paper by Apr. 1, 
1990, to Geneva Belford, Univ. of Illinois, 
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1304 W. Springfield Ave., Urbana, IL 61801, 
phone (217) 333-6684. 


Fifth Rocky Mountain Conf. on Artiffl- 
cial Intelligence: June 28-30, 1990, Las 
Cruces, N.M. Cosponsors: ACM et al. Submit 
three copies of paper by Apr. 1,1990, to Paul 
McKevitt, Computing Research Lab, Dept. 
3CRL, Box 30001, New Mexico State Univ., 
Las Cruces, NM 88003-0001, phone (505) 
646-5109, fax (505) 646-6218, Internet 
paul@nmsu.edu. 


Technical Univ. of Vienna, Applied Computer 
Science Dept., CD Lab for Expert Systems, 
Paniglgasse 16, 1040 Vienna, Austria, fax 43 
(222) 505-5304, e-mail nejdl@vexpert.at. 


( ffl ) IEEE 1990 Conf. on Software Mainte- 
nance Tools Fair: Nov. 26-29, 1990, 
San Diego. Submit proposal, abstract, and 
equipment list by Apr. 1,1990, to Paul Oman, 
College of Engineering, Univ. of Idaho, 
Moscow, ID 83843, phone (208) 885-6589, e- 
mail oman@ted.cs.uidaho.edu. 


ASIC 90, Third IEEE ASIC Seminar 
vs? and Exhibit: Sept. 17-21, 1990, Roches¬ 
ter, N.Y. Cosponsors: IEEE Rochester Sec¬ 
tion, ACM. Submit five copies of summary and 
abstract by Apr. 1, 1990, to Lynne Engelbre- 
cht, 170 Mt. Read Blvd., Rochester, NY 14611, 
phone (716) 328-2310, fax (716) 436-9370. 


Internal Audit Advanced Technology Fo¬ 
rum: Sept. 17-19, 1990, Orlando, Fla. Spon¬ 
sor: Inst, of Internal Auditors. Submit four cop¬ 
ies of paper by Apr. 1, 1990, to Frank Allen, 
IIA, 249 Maitland Ave., Altamonte Springs, 

FL 32701-4201. 


Fourth Conf. on Putting Methods and Tools 
into Practice as Aids to Design Information 
Systems: September 25-27, 1990, Nantes, 
France. Sponsor: Univ. de Nantes, Inst. Univ. 
de Technologie, Lab. d’lnformatique, Liana. 
Submit paper by Apr. 1, 1990, to H. Habrias, 3 
Rue du Marechal Jofffe, 44041 Nantes Cedex 
01, France, phone (33) 4030-6090, fax (33) 
4030-6001. 

1990 IEEE Workshop on Visual Languages: 

Oct. 4-6, 1990, Skokie, Ill: Cosponsors: Univ. 
of Pittsburgh et al. Submit abstract and paper 
by Apr. 1, 1990, to S.K. Chang, Computer Sci¬ 
ence Dept., Univ. of Pittsburgh, Pittsburgh, PA 
15260. 


Iecon 90, 16th Conf. of the IEEE Industrial 
Electronics Society: Nov. 27-30, 1990, Pa¬ 
cific Grove, Calif. Submit five copies of ab¬ 
stract and summary by Apr. 1, 1990, to Alfred 
C. Weaver, Computer Science Dept., Thornton 
Hall, Univ. of Virginia, Charlottesville, VA 
22903, phone (804) 982-2201, fax (804) 982- 
2214 (for authors in North and South Amer¬ 
ica); Adolf Habock, Siemens AG, Stromrich- 
terwerk Erlangen, Frauenauracher Str. 80, D- 
8520 Erlangen, West Germany, phone 49 (91) 
31 731-312, fax 49 (91) 31 732-148 (for Eu¬ 
rope); or Hiromasa Haneda, Electronics Engi¬ 
neering Dept., Kobe Univ., Rokko-dai, Nada- 
ku, Kobe City, Hyogo 675, Japan, phone 81 
(78) 881-1212, fax 81 (78) 861-7679 (for other 
regions). 

Fourth Southeastern Small-College Com¬ 
puting Conf.: Nov. 9-10, 1990, Hickory, N.C. 
Sponsor: Consortium for Computing in Small 
Colleges. Submit extended abstract by Apr. 1, 
1990, to Susan Dean, Samford Univ., 800 
Lakeshore Dr., Birmingham, AL 35229, Bitnet 
stdean@samford.bitnet. 

Int’l Workshop on Expert Systems in Engi¬ 
neering: Sept. 24-26, 1990, Vienna, Austria. 
Sponsor: Christian Doppler Expert Systems 
Lab, Univ. of Vienna. Submit five copies of 
paper by Apr. 1, 1990, to Wolfgang Nejdl, 


TAU 90, 1990 Int’l Workshop on Timing Is¬ 
sues in the Specification and Synthesis of 
Digital Systems: Aug. 15-17, 1990, Vancou¬ 
ver, B.C., Canada. Sponsor: ACM. Submit six 
copies of draft paper by Apr. 1, 1990, to Robert 
K. Brayton, Electrical Engineering and Com¬ 
puter Science Dept., Univ. of California at 
Berkeley, Berkeley, CA 94760. 

ICDT 90, Third Int’l Conf. on Database The¬ 
ory: Dec. 11-15, 1990, Paris. Sponsor: INRIA. 
Submit seven copies of extended abstract by 
Apr. 2, 1990, to Paris Kanellakis, ICDT 90, 
Brown Univ., Computer Science Dept., PO 
Box 1910, Providence, RI 02912, phone (401) 
863-7647, e-mail pck@cs.brown.edu; or 
Serge Abiteboul, INRIA, Domaine de Volu- 
ceau — Rocquencourt, BP 105, 78153 Le 
Chesnay Cedex, France; phone 33 (l)-3963- 
5537, fax 33 (1) 3963-5638, e-mail abitebou@ 
inria.inria.fr. 


PDCS 90, ISMM Int’l Conf. on Parallel and 
Distributed Computing and Systems: Oct. 
10-12, 1990, New York City. Sponsor: Int’l 
Society for Mini and Microcomputers. Submit 
three copies of abstract and paper by Apr. 2, 
1990, to R. Ammar, U155, Computer Science 
and Engineering Dept., Univ. of Connecticut, 
Storrs, CT 06268, fax (203) 486-0318. 


Supercomputing 90: Nov. 12-16, 1990, 
New York City. Cosponsor: ACM. Sub¬ 
mit five copies of paper by Apr. 15, 1990, to 
Daniel V. Pryor, Supercomputing Research 
Center, 17100 Science Dr., Bowie, MD 20715, 
phone (301) 805-7407, e-mail 
pryor@super.org. 

IEEE Workshop on the Management 
of Replicated Data: Nov. 7-9, 1990, 
Houston. Sponsor: IEEE Technical Commit¬ 
tee on Operating Systems. Submit eight copies 
of position statement by Apr. 15, 1990, to 
Jehan-Francois Paris, Computer Science 
Dept., Univ. of Houston, Houston, TX 77204- 
3475, phone (713) 749-3943, e-mail paris@ 
cs.uh.edu; Luis-Felipe Cabrera, IBM Almaden 
Research Center, 650 Harry Rd„ MC K55/803, 
San Jose, CA 95120-6099, phone (408) 927- 
1838. 


Tenth Rochester Forth Conf. on Embedded 

Systems: June 12-16, 1990, Rochester, N.Y. 
Submit abstract by Apr. 15, 1990, and paper by 
May 15, 1990, to Lawrence P. Forsley, Inst, for 
Applied Forth Research, 70 Elmwood Ave., 
Rochester, NY 14611, phone (716) 235-0168, 
fax (716) 328-6426, e-mail L.Forsley on Genie 
and LForsley on Bix and Delphi. 

ACM SIGSoft 90, Fourth Symp. on Software 
Development Environments: Dec. 3-5, 1990, 


Irvine, Calif. Submit six copies of paper and 
abstract of demonstration proposal by Apr. 16, 
1990, to Richard N. Taylor, Information and 
Computer Science Dept., Computer Science 
Bldg., Rm. 444, Parking Lot 18, Univ. of Cali¬ 
fornia, Irvine, CA 92717, e-mail taylor@ 
ics.uci.edu. 

Fourth Topical Meeting on Robotics and 
Remote Systems for Hazardous Environ¬ 
ments: Feb. 24-28, 1991, Albuquerque, N.M. 
Submit four copies of abstract by Apr. 16, 
1990, to Raymond W. Harrigan, Div. 1414, 
Sandia Nat’l Labs, Albuquerque, NM 87185, 
phone (505) 846-6278, fax (505) 846-7425. 

14th Western Educational Computing 
Conf.: Nov. 15-16, 1990, Irvine, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Submit two copies of paper by Apr. 
21, 1990, to Oliver Seely, Jr., California State 
Univ. at Dominguez Hills, Chemistry, 1000 E. 
Victoria St., Carson, CA 90747. 

1990 IEEE Workshop on VLSI Signal Pro¬ 
cessing: Nov. 7-9, 1990, San Diego, Calif. 
Submit three copies of extended summary or 
complete paper by Apr. 23,1990, to Patti Fen- 
stermacher, AT&T Bell Labs, 1243 S. Cedar 
Crest Blvd., Allentown, PA 18103, e-mail 
psf@aloft.att.com. 

( ffit ICCAD 90, IEEE Int’l Conf. on Com- 
puter-Aided Design: Nov. 11-15, 1990, 

Santa Clara, Calif. Cosponsor: IEEE Circuits 
and Systems Society. Submit 12 copies of ab¬ 
stract and paper by Apr. 27, 1990, to ICCAD 
90, c/o MP Associates, 7490 Clubhouse Rd., 
Suite 102, Boulder, CO 80301, phone (303) 
530-4562 or 4333. 


Second Int’l Conf. on Algebraic and Logic 
Programming: Oct. 1-3, 1990, Nancy, 

France. Submit five copies of paper by Apr. 27, 
1990, to Wolfgang Wechler, TU Braun¬ 
schweig, Theoretische Informatik, Postfach 
3329, D-3300 Braunschweig, West Germany, 
e-mail wechler@infbs.uucp. 


ICCV 90, Third Int’l Conf. on Com- 
viy puter Vision: Dec. 4-7, 1990, Osaka, Ja¬ 
pan. Submit four copies of paper by Apr. 30, 
1990, Saburo Tsuji, Osaka Univ., Control En¬ 
gineering Dept., Toyonaka, Osaka 560, Japan, 
e-mail tsuji@tsuji.ce.osaka-u.ac.jp. 


CASE 90, Fourth Int’l Workshop on 
Computer-Aided Software Engineer¬ 
ing: Dec. 5-8, 1990, Irvine, Calif. Sponsors: 
Int’l Workshop on CASE et al. Submit six cop¬ 
ies of position paper by Apr. 30,1990, to 
Wayne Stevens, IBM, 472 Wheelers Farms 
Rd., Milford, CT 06460-2757, phone (203) 
783-4432, fax (203) 783-7488. 


J. Intelligent Manufacturing plans a special 
issue in January 1991 on research in languages, 
frameworks, and databases. Submit paper by 
Apr. 30, 1990, to Evangelos Simoudis, Al Ap¬ 
plications Group, DEC, 290 Donald Lynch 
Blvd., MS DLB5-2/B4, Marlboro, MA 01752, 
phone (508) 490-8141. 

Third Int’l Symp. on Artificial Intelligence: 

Oct. 22-26, 1990, Monterrey, N.L. Mexico. 
Sponsors: ITESM (Inst. Tecnologico y de Es- 
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tudios Superiores de Monterrey) et al. Submit 
five copies of paper by Apr. 30,1990, to Hugo 
Terashima, Centro de Inteligencia Artificial, 
ITESM, Sue. de Correos “J”, C.P. 64849 Mon¬ 
terrey, N.L. Mexico, phone 52 (83) 58-2000, 
fax 52 (83) 58-0771. 


Second IEEE Symp. on Parallel and 

Distributed Processing: Dec. 10-12, 
1990, Dallas. Sponsor: IEEE Computer Soci¬ 
ety Dallas Section. Submit seven copies of pa¬ 
per by May 1,1990, to Behrooz Shirazi, Com¬ 
puter Science and Engineering Dept., South¬ 
ern Methodist Univ., Dallas, TX 75275, phone 
(214) 692-2874, e-mail shirazi%smu.uucp@ 
uunet.uu.net; or Hal Sudborough, CS Dept., 
Univ. of Texas at Dallas, PO Box 830688, 
Richardson, TX 75083, phone (214) 690-2184. 

11th Real-Time Systems Symp.: Dec. 

5-7, 1990, Orlando, Fla. Sponsor: IEEE 
Computer Society Technical Committee on 
Real-Time Computing. Submit five copies of 
paper by May 1,1990, to Jane W.S. Liu, 1304 
W. Springfield Ave., Computer Science Dept., 
Univ. of Illinois, Urbana, IL 61801-3082, 
phone (217) 333-0135, e-mail janeliu@ 
cs.uiuc.edu. 


ligence: Nov. 6-9, 1990, Washington, DC. Co¬ 
sponsors: Rutgers Univ. et al. Submit four cop¬ 
ies of panel proposal, tutorial proposal, and full 
paper by May 15,1990, to W.T. Tsai, Com¬ 
puter Science Dept., 4-192 EE/CS Bldg., 200 
Union St. SE, Univ. of Minnesota, Minneapo¬ 
lis, MN 55455, phone (612) 625-6371. 


Second SIAM Conf. on Linear Algebra in 
Signals, Systems, and Control: Nov. 5-9, 
1990, San Francisco, Calif. Sponsor: Society 
for Industrial and Applied Mathematics. Sub¬ 
mit abstract of paper or poster by May 16, 
1990, to SIAM, 3600 University City Science 
Center, Philadelphia, PA 19104-2688, phone 
(215) 382-9800, fax (215) 386-7999, e-mail 
siam@ wharton.upenn.edu. 


OTm Sixth Computer Security Applica- 
tions Conf.: Dec. 3-7, 1990, Tucson, 
Ariz. Sponsors: American Society for Indus¬ 
trial Security et al. Submit five copies of paper 
or panel proposal by May 18,1990, to Ronald 
A. Gove, Booz-AUen and Hamilton, 4330 
East-West Highway, Bethesda, MD 20814, 
phone (301) 951-2395, e-mail gove@dock 
master.ncsc.mil. 


AIRIES 90, Al Research in the Environ¬ 
mental Sciences Workshop: Sept. 25-27, 
1990, Montreal, Que., Canada. Cosponsors: 
Univ. of Quebec at Montreal, Centre Re- 
searche Informatique de Montreal. Submit ab¬ 
stract for oral presentation, poster presenta¬ 
tion, or demonstration by May 1,1990, to 
Rosemary M. Dyer, GL/LYP, AIRIES 90, Air 
Force Geophysics Lab, Hanscom Air Force 
Base, MA 01731, fax (617) 377-4498. 

Al 90, Australian Joint Artificial Intelli¬ 
gence Conf.: Nov. 21-23, 1990, Perth, West¬ 
ern Australia. Sponsor: Australian Computer 
Society. Submit paper by May 11,1990, to Les 
Kitchen, Univ. of Western Australia, Com¬ 
puter Science Dept., Nedlands, Western Aus¬ 
tralia, 6009, phone 61 (9) 380-2281, e-mail 
ai90@wacsvax.oz.au. 

TAI 90, Second Computer Society 
Int’l Conf. on Tools for Artificial Intel- 


Electrosoft plans a special issue on software 
for semiconductor device and circuit model¬ 
ing. Publisher: Computational Mechanics 
Publications. Submit paper by May 20, 1990, 
to E. Langer, Inst, fur Mikroelektronik, Tech- 
nische Universitat Wien, Gusshausstrasse 27- 
29, Wien, Austria 1040, phone 43 (222) 58801. 

15th Conf. on Local Computer Net¬ 
works: Oct. 1-3, 1990, Minneapolis, 
Minn. Submit five copies of paper by May 22, 
1990, to Marc Cohn, Advanced Development 
Div., Raychem Corp., 300 Constitution Dr., 
Menlo Park, CA 94025-1164, phone (415) 
361-3902, fax (415) 361-6099. 

Symp. on Object-Oriented Programming 
Emphasizing Practical Applications: Sept. 
14-15, 1990, Poughkeepsie, N.Y. Sponsor: 
Marist College. Submit three copies of full pa¬ 
per or panel proposal by May 31,1990, to Fred 
Benfer, IBM Corporate Education, Thom- 
wood, NY 10594, hzap@maristb.bitnet. 


Moving? 

PLEASE NOTIFY 

Name (Please Print) 

US 4 WEEKS 

IN ADVANCE 

New Address 



City 

State/Country Zip 

MAIL TO; 

IEEE Service Center 

445 Hoes Lane 
Piscataway, NJ 08854 

ATTACH 

LABEL 

HERE 

• This notice of address change will apply to all 

IEEE publications to which you subscribe. 

• List new address above. 

• If you have a question about your subscription, 
place label here and clip this form to your letter. 


Seventh Israeli Conf. on Artificial Intelli¬ 
gence and Computer Vision: Dec. 26-27, 
1990, Tel Aviv. Submit four copies of full pa¬ 
per by June 1,1990, to A. Bruckstein, Faculty 
of Computer Science, Technion, 32000 Haifa, 
Israel, e-mail freddy@techsel.bitnet. 

ISCIA 5, Fifth Int’l Symp. on Computer and 
Information Sciences: Oct. 30-Nov. 2, 1990, 
Cappadocia, Nevsehir, Turkey. Sponsors: Is¬ 
tanbul Technical Univ. et al. Submit full paper 
by June 1,1990, to A. Emre Harmanci, Is¬ 
tanbul Technical Univ., Bilgi Islem Merkezi, 
Ayazaga, 80626 Istanbul, Turkey, phone 090 
(1) 176-3254, fax 090 (1) 176-1734, e-mail 
harmanci@tritu.bitnet. 

Micro 23, 23rd Symp. and Workshop 

on Microprogramming and Micro¬ 
architecture: Nov. 27-29, 1990, Orlando, Fla. 
Cosponsor: ACM. Submit five copies of full 
paper by June 15, 1990, to Chris Papachristou, 
Case Western Reserve Univ., Computer Engi¬ 
neering and Science Dept., Cleveland, OH 
44106, phone (216) 368-5277, e-mail cap@ 
alpha.ces.cwm.edu; or Vicki Allan, Utah State 
Univ., Computer Science Dept., Logan, UT 
84321-4205, phone (801) 750-2022, e-mail 
allanv@usu.bitnet. 


Fifth Int’l Conf. on Modeling Techniques 
and Tools for Computer Performance 
Evaluation: Feb. 13-15, 1991. Torino, Italy. 
Submit five copies of paper by June 15, 1990, 
to Gianfranco Balbo, Dip. di Informatica, 
Univ. di Torino, Corso Svizzera, 185, 10149 
Torino, Italy, phone 39 (11) 771-2002, fax 39 
(11) 751-603, e-mail balbo@itoinfo.bitnet. 

tjfjl 1990 IEEE Workshop on Languages 
vS? and Architectures for Automation: 

Dec. 19-21, 1990, Honolulu, Hawaii. Spon¬ 
sors: Pacific Int'l Center for High Technology 
Research et al. Submit five copies of paper by 
June 30,1990, to D.Y.Y. Yun, Univ. of Ha¬ 
waii, 711 Kapiolani Blvd., Suite 200, Hono¬ 
lulu, HI 96813-5249, phone (808) 539-1532, 
fax (808) 941-1399. 


IAPR Workshop on Machine Vision Appli¬ 
cations: Nov. 28-30, 1990, Tokyo. Sponsor: 
Int’l Assoc, for Pattern Recognition. Submit 
four copies of summary by June 30,1990, to 
Mikio Takagi, Inst, of Industrial Science, 

Univ. of Tokyo, 7-22-1 Roppongi, Minatoku, 
Tokyo 106, Japan, phone 81 (3) 479-0289, fax 
81 (3) 423-2834, e-mail takagi@tkl.iis.u- 
tokyo.ac.jp. 

IFIP Working Conf. on Modeling in Com¬ 
puter Graphics: Apr. 8-12, 1991, Tokyo. 
Sponsor: IFIP TC 5/WG 5.10. Submit five cop¬ 
ies of paper by June 30, 1990, to Tosiyasu L. 
Kunii, Information Science Dept., Faculty of 
Tokyo, Univ. of Tokyo, 7-3-1 Hongo, Bunkyo- 
ku, Tokyo 113, Japan, phone 81 (3) 816-1783, 
fax 81 (3) 818-4607, e-mail b3975@tan 
sei.cc.u-tokyo.ac.jp. 

IQ)} IEEE Trans. Computers plans a special 
issue on protocol engineering. Submit 
six copies of manuscript by July 1,1990, to 
Ming T. (Mike) Liu, CIS Dept., Ohio State 
Univ., 2036 Neil Ave., Columbus, OH 43210- 
1277, phone (614) 292-1837. 
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CALENDAR 


March 1990 


Second Oregon Workshop on Software Met¬ 
rics, Mar. 19-20, Portland, Ore. Sponsors: 
Portland State Univ. et al. Contact Warren Har¬ 
rison, Computer Science Dept., Portland State 
Univ., PO Box 751, Portland, OR 97207-0751, 
phone (503) 464-3108. 

NCGA 90, Mar. 19-22, Anaheim, Calif. Con¬ 
tact Nat’l Computer Graphics Assoc., 2722 
Merrilee Dr., Suite 200, Fairfax, VA 22031, 
phone (703) 698-9600. 

UK IT (Information Technology) 1990 
Conf., Mar. 19-22, Southampton, UK. Spon¬ 
sors: IEE et al. Contact Conf. Services, Institu¬ 
tion of Electrical Engineers, Savoy PI., London 
WC2R 0BL, UK, phone 44 (1) 240-1871. 

Southcon 90, Mar. 20-22, Orlando, Fla. Spon¬ 
sors: IEEE Florida Council et al. Contact 
Southcon 90, 8110 Airport Blvd., Los Angeles, 
CA 90045. 


Eighth Built-In Self-Test Workshop, 
Mar. 21-23, Charleston, S.C. Sponsors: 
IEEE Test Technology Committee. Contact 
Richard Sedmak, Self-Test Services, 6 Lin- 
denwold Terr., Ambler, PA 19002, phone 
(215) 628-9700. 


Computer Center Management Symp., 
Mar. 21-23, St. Louis. Sponsor: ACM Special 
Interest Group on University and College 
Computing Services. Contact Larry Wester- 
meyer, Univ. of Missouri at St. Louis, 8001 
Natural Bridge Rd., St. Louis, MO 63121, 
phone (314) 553-6000, e-mail slwwestt® 
umslvma. 


IPCCC, Ninth IEEE Int’i Phoenix Conf. on 
Computers and Communications, Mar. 21- 

24, Scottsdale, Ariz. Cosponsor: IEEE Com¬ 
munications Society. Contact Forouzan Gol- 
shani, Computer Science Dept., Arizona State 
Univ., Tempe, AZ 85287, phone (602) 965- 
2855. 


Hannover Fair Cebit 90, Mar. 21-28, Han¬ 
nover, West Germany. Contact Hannover Fairs 
USA, 103 Carnegie Center, Princeton, NJ 
08540, phone (609) 987-1202; or German- 
Arab Chamber of Commerce, 3, Abu El Feda 
Bldg., Cairo-Zamalek, PO Box 385, Egypt, 
phone 20 (02) 3-41-36-62. 

)^j^| 1990 Symp. on Interactive 3D Graph- 
ics. Mar. 25-28, Snowbird, Utah. Spon¬ 
sors: US Office of Naval Research et al. Con¬ 
tact Richard Riesenfeld, Univ. of Utah, Com¬ 
puter Science Dept., 3190 Merrill Engineering 
Bldg., Salt Lake City, Utah 84112, phone (801) 
581-8224. 


In the accompanying Calendar, the IEEE Computer Society logo identifies 
the conferences the society is sponsoring and participating in. Other confer¬ 
ences of interest to our readers, as well as their sponsors, are also listed. 

For inclusion in Call for Papers or Calendar, submit information at least six 
weeks before the month of publication (i.e., for the May 1990 issue, send infor¬ 
mation for receipt by March 15, 1990) to Chuck Governale, Calendar Dept., Com¬ 
puter, PO Box 3014, Los Alamitos, CA 90720-1264. 


Conf. on Al, Simulation, and Planning 
in High-Autonomy Systems, Mar. 26- 

27, Tucson, Ariz. Cosponsors: Univ. of Ari¬ 
zona et al. Contact Bernard Zeigler, Electrical 
and Computer Engineering Dept., Office of 
Engineering Professional Development, Univ. 
of Arizona, Box 9 Harvill Bldg., Tucson, AZ 
85721, phone (602) 621-3054 or (602) 743- 
9551. 

ICSE 12, 12th Int’i Conf. on Software 
Engineering, Mar. 26-30, Nice, France. 
Cosponsors: ACM, AFCET. Contact Francois- 
Regis Valette, CERT/DERI, PO Box 4026-2, 
Ave. Edouard Belin-31055 Toulouse, France, 
phone (33) 61-55-71-11; ICSE 12, AFCET, 

156 Bd. Pereire, 75017 Paris, France; or IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

1990 Int’l Conf. on Extending Data- 
base Technology, Mar. 26-30, Venice, 
Italy. Cosponsors: EDBT Foundation et al. 
Contact Michael L. Brodie, Intelligent Data¬ 
base Systems Dept., GTE Labs, 40 Sylvan Rd., 
MS 62, Waltham, MA 02254, phone (617) 466- 
2256. 


Johnson, HP Labs, PO Box 10490, Palo Alto, 
CA 94303-0969, phone (415) 857-7661. 


April 1990 


CHI 90,1990 Conf. on Human Factors in 
Computing Systems, Apr. 1-5, Seattle. Spon¬ 
sor: ACM. Contact Toni MacHaffie, CHI 90, 
PO Box 5847, Beaverton, OR 97006-5847, 
phone (503) 591-1981; or ACM, 11 W. 42nd 
St., New York, NY 10036. 

Sixth MIT Conf. on Advanced Research in 
VLSI, Apr. 2-4, Cambridge, Mass. Contact 
Microsystems Research Center, Rm. 39-321, 
MIT, Cambridge, MA 02139, phone (617) 253- 
8138. 

Ninth Symp. on Principles of Database Sys¬ 
tems, Apr. 2-4, Nashville, Tenn. Sponsor: 
ACM. Contact Daniel J. Rosenkrantz, Com¬ 
puter Science Dept., State Univ. of New York 
at Albany, Albany, NY 12222, e-mail djr@ 
albanycs.albany.edu. 


1990 AAAI Spring Symp. on the Theory and 
Application of Minimal-Length Encoding, 
Mar. 27-29, Stanford, Calif. Contact Edwin 
Pednault, AT&T Bell Laboratories, Rm. 4F- 
611, Crawfords Comer Rd., Holmdel, NJ 
07733, phone (201) 949-1074. 

Supercomputing Japan 90, Mar. 27-29, To¬ 
kyo. Cosponsors: US Commerce Dept, et al. 
Contact Meridian Pacific Group, 116 E. 
Blithedale Ave., Suite 2, Mill Valley, CA 
94941, phone (415) 381-2255. 


19th Int’l Programmable Controller/Ex¬ 
pert Systems Conf., Apr. 3-5, Detroit. Spon¬ 
sor: Engineering Society of Detroit. Contact 
ESD, 100 Farnsworth, Detroit, MI 48202, 
phone (313) 832-5400. 

Hydrosoft 90, Int’l Conf. on Hydraulic Engi¬ 
neering Software, Apr. 3-5, Boston. Sponsor: 
Computational Mechanics Inst. Contact Liz 
Newman, CMI, Ashurst Lodge, Ashurst, 
Southampton, S04, 2AA, England, phone 042 
(129) 3223. 


Mathematical Sciences Inst. Symp., Mar. 
29-31, Ithaca, NY. Contact Diana Drake, MSI, 
Cornell Univ., 201 Caldwell Hall, Ithaca, NY 
14853-2602, phone (607) 255-7740. 

PDC 90, Conf. on Participatory Design of 
Computer-Based Applications, Mar. 31- 
Apr. 1, Seattle. Sponsors: Computer Profes¬ 
sionals for Social Responsibility, Computers 
in the Workplace Working Group. Contact Jeff 


Flairs 90, Florida Al Research Symp., Apr. 
3-6, Cocoa Beach, Fla. Contact Avelino J. 
Gonzalez, Computer Engineering Dept., Univ. 
of Central Florida, Orlando, FL 32816, phone 
(407) 281-5027. 

Fourth Parallel Processing Symp., 
Apr. 4-6, Fullerton, Calif. Sponsor: 
IEEE Computer Society Orange County Chap¬ 
ter. Contact Larry H. Canter, c/o Computer 
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Systems Approach, 1140 S. Raymond Ave., 
Suite B., Fullerton, CA 92631, phone (714) 
738-3414. 


tf Kt VHDL Users’ Group Spring Meeting, 
Apr. 4-6, Boston. Contact Frederick 
Hinchliffe, CLSI, Suite 210, 15245 Shady 
Grove Rd„ Rockville, MD 20850, phone (301) 
963-5200. 


/gtjh 1990 Symp. on Applied Computing, 
nAx Apr. 5-6, Fayetteville, Ark. Cosponsors: 
Univ. of Arkansas, UA Student ACM Chapter. 
Contact Hal Berghel, Univ. of Arkansas, Com¬ 
puter Science Dept., Fayetteville, AR 72701, 
phone (501) 575-7343. 

Computer Science Curricula for the 
1990s, Apr. 5-7, Providence, R.I. Con¬ 
tact Peter Wegner, Box 1910, Brown Univ., 
Providence, RI 02812, phone (401) 863-7632. 

OC 90, Int’l Topical Meeting on Opti- 
NftZ cal Computing, Apr. 8-12, Kobe, Japan. 
Cosponsors: SPIE et al. Contact S. Ishihara, 
Business Center for Academic Societies Ja¬ 
pan, 3-23-1, Hongo, Bunkyo-ku, Tokyo 113, 
Japan, phone 81 (3) 817-5831. 

1990 IEEE VLSI Test Workshop, Apr. 
10-11, Atlantic City, N.J. Cosponsor: 
IEEE Philadelphia Section. Contact Wesley E. 
Radcliffe, IBM E. Fishkill, Dept. 277, Bldg. 
321-5E1, Hopewell Junction, NY 12533, 
phone (914) 894-4346. 


Conf. on Computer Modeling in the Envi¬ 
ronmental Sciences, Apr. 10-11, Keyworth, 
UK. Cosponsors: Natural Environment Re¬ 
search Council, Inst, of Mathematics and its 
Applications. Contact G. Darwall, NERC, 
Holbrook House, Station Road, Swindon, 
Wilts, SN1 IDE, England. 


Disco 90, Int’l Symp. on Design and Implem¬ 
entation of Symbolic Computation Systems, 
Apr. 10-12, Capri, Italy. Contact Alfonso Mi- 
ola. Dip. Informatica e Sistemistica, Via Buon¬ 
arroti, 12, 00185 Roma, Italy, phone 39 (6) 
731-2367. 


Subcommittee on Software Reliability 
Engineering, Apr. 12-13, Washington, 
DC.. Sponsor: IEEE Computer Society Tech¬ 
nical Committee on Software Engineering. 
Contact A. Frank Ackerman, Inst, for Zero De¬ 
fect Software, 200 Runnymede Pkwy., New 
Providence, NJ 07974, phone (201) 464-2980. 


Western Educational Computing Work¬ 
shops, Apr. 12-13, Northridge, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Contact Judah Rosenwald, Extended 
Education, NAD 153, San Francisco State 
Univ., 1600 Holloway, San Francisco, CA 
94132, phone (415) 338-1212. 


fljj Applications of Artificial Intelligence 
VIII, Apr. 15-18, Orlando, Fla. Cospon¬ 
sor: SPIE. Contact Mohan M. Trivedi, Univ. of 
Tennessee, Electrical and Computer Engineer¬ 
ing, Ferris Hall, Knoxville, TN 37996-2100, 
phone (615) 974-5450. 


1990 Technical Symp. on Optical Engineer¬ 
ing and Photonics in Aerospace Sensing, 


Apr. 16-20, Orlando, Fla. Sponsor: SPIE. Con¬ 
tact Int’l Society for Optical Engineering, PO 
Box 10, Bellingham, WA 98227-0010, phone 
(206) 676-3290. 


13th IEEE Workshop on Design for 
'5*7 Testability, Apr. 17-20, Vail, Colo. 
Contact T.W. Williams, IBM, PO Box 1900, 
Dept. 67A/021B, Boulder. CO 80301-9191, . 
phone (303) 924-7692. 


10th European Meeting on Cybernetics and 
Systems Research, Apr. 17-20, Vienna, Aus¬ 
tria. Sponsor: Austrian Society for Cybernetic 
Studies. Contact Robert Trappl, Cybernetics 
and Artificial Intelligence Dept., Univ. of Vi¬ 
enna, Freyung 6/2, A-1010 Vienna, Austria, 
phone 43 (222) 5353-2810. 


^ First Int’l Conf. on Systems Integra¬ 
ls^ tion, Apr. 23-26, Morristown, N.J. 
Sponsor: New Jersey Inst, of Technology. 
Contact Peter A. Ng, Computer and Informa¬ 
tion Science Dept., New Jersey Inst, of Tech¬ 
nology, Newark, NJ 07102, phone (201) 596- 
3387, fax (201) 596-5777, e-mail ng_p@ 
vienna.njit.edu. 


1990 Eastern Multiconf., Apr. 23-26, Nash¬ 
ville, Tenn. Sponsor: Society for Computer 
Simulation. Contact SCS, PO Box 17900, San 
Diego, CA 92117-7900, phone (619) 277- 
3888. 


First European Conf. on Computer Vision, 
Apr. 23-27, Antibes, France. Sponsor: INRIA. 
Contact C. Juncker, Inst. Nat’l de Recherche en 
Informatique et en Automatique, Bureau des 
Relations Exterieures, Sophia Antipolis, 2004, 
Route des Lucioles, 06565 Valbonne Cedex, 
France, phone 33 (93) 65-78-60. 

/£Jj\ COIS 90, Conf. on Office Information 
Systems, Apr. 25-27, Cambridge, Mass. 
Cosponsor: ACM. Contact Robert B. Allen, 
Rm. 2A-367, Bellcore, 444 South St., Morris¬ 
town, NJ 07960-1910, phone (201) 829-4280 
or 4315. 

SETA 1, First Int'l Symp. on Environ- 
ments and Tools for Ada, Apr. 30-May 

2, Redondo Beach, Calif. Cosponsor: ACM. 
Contact Stowe Boyd, Meridian Software Sys¬ 
tems, 23141 Verdugo Dr., Suite 105, Laguna 
Hills, CA 92653, phone (714) 727-0700, ext. 
222; or Dewayne E. Perry, AT&T Bell Labora¬ 
tories, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2529. 


11th Structured Development Forum, Apr. 
30-May 3, San Diego, Calif. Contact Gail 
Phipps or Judith G. Hays, Computer Sciences 
Corp., 1321 Mercedes Dr., Hanover, MD 
21076, phone (301) 859-0400. 


May 1990 


IAAI 90, Second Conf. on Innovative Appli¬ 
cations of Artificial Intelligence, May 1-3, 

Washington, DC. Sponsor: American Assoc, 
for Artificial Intelligence. Contact AAAI, 445 


Burgess Dr., Menlo Park, CA 94025, phone 
(415) 328-3123. 

24th Carnahan Conf. on Security Technol¬ 
ogy, May 2-4, Lexington, Ky. Contact Glenna 
Vickers, Office of Engineering Continuing 
Education, Univ. of Kentucky, 305 Slone 
Bldg., Lexington, KY 40506-0053, phone 
(606) 257-4296. 


21st Pittsburgh Conf. on Modeling and 
Simulation, May 3-4, Pittsburgh. Sponsors: 
Univ. of Pittsburgh et al. Contact William G. 
Vogt or Marlin H. Mickle, Modeling and Simu¬ 
lation Conf., 348 Benedum Engineering Hall, 
Univ. of Pittsburgh, Pittsburgh, PA 15261. 


10th IEEE Symp. on Mass Storage Sys- 
vSZ terns, May 6-10, Monterey, Calif. Con¬ 
tact Bernard T. O'Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268. 


frfj l 1990 IEEE Symp. on Research in Secu- 
rity and Privacy, May 7-9, Oakland. 
Calif. Contact Deborah Cooper, Unisys, 5731 
Slauson Ave., Culver City, CA 90230, phone 
(213) 338-3727. 


AISIG 90, Fifth Al Systems in Govern- 
ment Conf., May 7-11, Washington, 
DC. Cosponsors: Mitre et al. Contact Barry G. 
Silverman, Inst, for Al, George Washington 
Univ., 2021 K St., Suite 710, Washington, DC 
20006, phone (202) 676-5112. 


Fourth Int’l Symp. on Knowledge Engineer¬ 
ing, May 7-11, Barcelona, Spain. Sponsor: 
Madrid Polytechnic Univ. Contact Jose R. 
Chelala, ISKE, Alvarez de Baena, 3-2, 28006 
Madrid, Spain. 

CompEuro 90, IEEE Int’l Conf. on 
Computer Systems and Software En¬ 
gineering, May 8-10, Tel Aviv. Cosponsors: 
IEEE Region 8, IEEE Israel Section, IEEE 
Computer Society Israel Chapter. Contact 
CompEuro 90 Conf. Secretariat, c/o ORTRA, 2 
Kaufman St., PO Box 50432, Tel Aviv 61500, 
Israel, phone 972 (3) 664-825, fax 972 (3) 660- 
952. 


JISI 90, Computer Science and Deci- 
sion Support, May 9-11, Tunis, Tunisia. 
Contact M. Ben Ahmed, ENSI, 16 rue Bolo, 
Montplaisir 1002, Tunis Le Belvedere, Tuni¬ 
sia, phone 216 (1) 780-394. 

Seventh IEEE Workshop on Real- 
^47 Time Operating Systems and Soft¬ 
ware, May 10-11, Charlottesville, Va. Co¬ 
sponsor: Office of Naval Research. Contact 
Robert P. Cook, Computer Science Dept., 
Univ. of Virginia, Thornton Hall, Charlottes¬ 
ville, VA 22903, phone (804) 924-7605. 


First IEEE Int’l Conf. on Applications of In¬ 
dustrial Electronics Systems, May 13-17, 

Jerusalem, Israel. Sponsor: IEEE Israel Sec¬ 
tion. Contact Moshe Harpaz, Kibbutz Ein- 
Carmel, D.N. Hof Carmel 30860, Israel, phone 
(972) 4-844410. 


1990 IEEE Int’l Conf. on Robotics and Auto¬ 
mation, May 13-18, Cincinnati, Ohio. Spon¬ 
sor: IEEE Robotics and Automation Society. 
Contact Robotics and Automation Conf., PO 
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tgjk Workshop on Interconnections 

Within High-Speed Digital Systems, 
May 14-16, Santa Fe, N.M. Cosponsors: IEEE 
Communications Society et al. Contact Randal 
Moulic, IBM Research Div., PO Box 704, Rm. 
H4-A04, Yorktown Heights, NY 10598, phone 
(914) 789-7321. 

1990 Society for Information Display Int’l 
Symp., May 14-18, Las Vegas. Contact How¬ 
ard L. Funk, IBM Corp., 10/641 3B-60, Old Or¬ 
chard Rd„ Armonk, NY 10504, phone (914) 
765-6409. 

43rd SPSE Conf., May 20-25, Rochester, 

N.Y. Sponsor: SPSE (Society for Imaging Sci¬ 
ence and Technology). Contact Michael M. 
Shahin, Xerox Corp., Webster Research Cen¬ 
ter, 800 Phillips Rd„ 0114-38D, Webster, NY 
14580, phone (716) 422-2011. 

Fifth Conf. on Artificial Intelligence 
vAy for Space Applications, May 22-23, 

Huntsville, Ala. Cosponsors: IEEE Computer 
Society Huntsville Chapter et ai. Contact Con¬ 
tinuing Education Div., Univ. of Alabama in 
Huntsville, Tom Bevill Center 285-1, Hunts¬ 
ville, AL 35899, phone (800) 448-4035 or 
(205) 895-6372. 

/^jk First Conf. on Visualization in Bio- 
medical Computing, May 22-25, At¬ 
lanta. Cosponsors: Nat’1 Science Foundation 
et al. Contact Norberto Ezguerra, Bioengineer¬ 
ing Center, Georgia Tech, Atlanta, GA 30332, 
phone (404) 894-7026 or 3964. 


/gfjk Euro ASIC 90, May 28-June 1, Paris. 
N=y Contact Gabriele Saucier, Inst. Nat'l 
Polytechnique de Grenoble/CSI, 46, avenue 
Felix Viallet, 38931 Grenoble Cedex, France, 
phone 33 (I) 76-57-46-87. 

ICDCS 10, 10th Int’l Conf. on Distrih- 
vjy uted Computing Systems, May 28- 
June 1, Paris. Cosponsor: INRIA. Contact R. 
Popescu-Zeletin, GMD-FOKUS, Harden- 
bergplatz 2, D-1000 Berlin 12, West Germany, 
phone 49 (30) 25499-206; Jack Stankovic, 
Computer and Information Science Dept., 
Univ. of Massachusetts, Amherst, MA 01003, 
phone (413) 545-0720; or ICDCS 10, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 


11th Conf. of the Canadian Applied Mathe¬ 
matics Society, May 29-June 1, Halifax, N.S., 
Canada. Cosponsors: CAMS et al. Contact 
Mary Meidell, Continuing Education Dept., 
Technical Univ. of Nova Scotia, PO Box 1000, 
Halifax, N.S., Canada B3J 2X4, phone (902) 
429-8300, ext. 2420. 


June 1990 


£§2k CBMS 90, Third IEEE Symp. on Com- 
puter-Based Medical Systems, June 3- 

6, Chapel Hill, N.C. Cosponsor: IEEE Engi¬ 
neering in Medicine and Biology Society. Con¬ 
tact James N. Brown, Jr., Research Triangle 
Inst., 3040 Cornwallis, Research Triangle 
Park, NC 27709, phone (919) 541-9675. 


SIGMetries 90, May 22-25, Boulder, Colo. 
Sponsor: ACM. Contact Gary J. Nutt, Univ. of 
Colorado, Boulder, CO 80301; or Herb 
Schwetman, MCC, 3500 W. Balcones Center 
Dr., Austin, TX 78759, phone (512) 338-3428. 

20th Int’l Symp. on Multiple-Valued 

Logic, May 23-25, Charlotte, N.C. Con¬ 
tact George Epstein, Computer Science Dept., 
Univ. of North Carolina at Charlotte, 214 Ken¬ 
nedy Bldg., Charlotte, NC 28223, phone (704) 
547-4566; or Carolyn F. Blalock, Office of 
Continuing Education, Univ. of North Caro¬ 
lina at Charlotte, Charlotte, NC 28223, phone 
(704) 547-4861. 

1990 American Control Conf., May 23-25, 

San Diego, Calif. Sponsor: American Auto¬ 
matic Control Council. Contact Dagfinn 
Gangsaas, Boeing Advanced Systems, PO Box 
3707, MS 33-12, Seattle, WA 98124-2207, 
phone (206) 393-6852. 


ICCI 90, Int’l Conf. on Computing and In¬ 
formation, May 23-26, Niagara Falls, Can¬ 
ada. Sponsor: Natural Sciences and Engineer¬ 
ing Research Council of Canada. Contact Wal- 
demar W. Koczkodaj, ICCI 90, Laurentian 
Univ., CoSc, Sudbury, Ont., Canada P3E 2C6. 


17th Int’l Symp. on Computer Archi- 
tecture, May 28-31, Seattle. Cosponsor: 
ACM. Contact Jean L. Baer or Larry Snyder, 
Univ. of Washington, Computer Science 
Dept., FR-35, Seattle, WA 98195, phone (206) 
543-1695. 


Spring Comdex, June 3-6, Atlanta. Contact 
Interface Group, 300 First Ave., Needham, 

MA 02194, phone (617) 449-6600. 

tjjjk IEEE Infocom 90, Ninth Conf. on 

Computer Communications, June 3-7, 

San Francisco. Cosponsor: IEEE Communica¬ 
tions Society. Contact Infocom 90, IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

|£J£k I.ICS 90, Fifth Symp. on Logic in Com- 
puter Science, June 4-7, Philadelphia. 
Contact Albert Meyer, Computer Science Lab, 
545 Technology Square, NE 43-315, Cam¬ 
bridge, MA 02139, phone (617) 253-6024. 

t^jk Int’l Workshop on Rapid System 
Prototyping, June 5-7, Triangle Re¬ 
search Park, N.C. Contact Kenneth Anderson, 
Siemens Corporate Research, 755 College Rd. 
E„ Princeton, NJ 08540, phone (609) 734-6550. 


Eurographics Workshop on Object-Orien¬ 
ted Graphics, June 6-8, Konigswinter, Fed¬ 
eral Republic of Germany. Sponsors: 
Eurographics and German Society for Infor¬ 
matics. Contact Marja Hegt, 0-0 Graphics 
Workshop, CWI, Kruislaan 413, 1098 SJ Am¬ 
sterdam, The Netherlands, phone 31 (20) 592- 
4058. 


ACL 90, 28th Conf. of the Assoc, for Compu¬ 
tational Linguistics, June 6-9, Pittsburgh. 
Contact Don Walker, Bellcore, MRE 2A379, 


445 South St., Box 1910, Morristown, NJ 
07960-1910, phone (201) 829-4312. 

1990 European Simulation Multiconf., June 
10-13, Nuremberg, Federal Republic of Ger¬ 
many. Sponsor: Society for Computer Simula¬ 
tion Inf I. Contact Bemd Schmidt, Univ. Er¬ 
langen, Computer Science Dept., D-8520, Er¬ 
langen, FRG, phone (49) 9131-857-278; or 
SCS Int’l, c/o Philippe Geril, Coupure Links 
653, B-9000 Ghent, Belgium, phone (32) 91- 
23-69-61. 


Int’l Workshop on Algorithms and Parallel 
VLSI Architectures, June 10-16, Pont-a- 
Mousson, France. Cosponsors: IEEE, Eurasip. 
Contact Alle-Jan van der Veen, Electrical 
Engineering Dept., Delft Univ. of Technology, 
2628 CD Delft, The Netherlands, phone (31) 
1578-1442. 

IFIP Workshop on Design and Test of 

ASICs, June 11-12, Hiroshima, Japan. 
Cosponsors: Information Processing Society 
of Japan et al. Contact Kozo Kinoshita, Hiro¬ 
shima Univ., 1-1-80 Higashisendacho, Naka- 
ku, Hiroshima-shi 730, Japan, phone 81 (87) 
249-9150. 


19th Mumps Users’ Group Meeting, June 
11-15, Orlando, Fla. Contact Mumps Users’ 
Group, 4321 Hartwick Rd., Suite 100, College 
Park, MD 20740, phone (301) 779-6555. 

1990 ACM Int’l Conf. on Supercomputing, 
June 11-15, Amsterdam. Contact E. Gallopou- 
los, Univ. of Illinois CSRD, 305 Talbot Lab, 
104 S. Wright St., Urbana, IL 61801-2932 (for 
North and South America); John R. Gurd, 
Computer Science Dept., Univ. of Manchester, 
Oxford Road, Manchester Ml3 9PL, UK 
(Europe and Africa); or Yoichi Muraoka, Elec¬ 
trical Engineering Dept., Waseda Univ., 3-4-1 
Okubo, Shinjuku-ku, Tokyo, Japan (Japan and 
the Far East). 


Usenix Summer 1990 Technical Conf., June 
11-15, Anaheim. Contact John R. Mashey, 
Anaheim Usenix Technical Program, MIPS 
Computer Systems, 930 Arques Ave., Sunny¬ 
vale, CA 94086, phone (408) 991-0253. 


Computer Security Foundations III, 
June 12-14, Franconia, N.H. Contact 
Tom Haigh, SCTC, 2855 Anthony Lane South, 
St. Anthony, MN 55418, phone (612) 782-7145. 


Ninth Inf I Conf. on Analysis and Optimiza¬ 
tion of Systems, June 12-15, Antibes, France. 
Sponsor: INRIA. Contact Conf. Secretariat, 
INRIA, Service des Relations Exterieures, 
Domaine de Voluceau—BP 105, 78153 Le 
Chesnay Cedex, France, phone 33 (l)-39-63- 
5500. 


Tenth Rochester Forth Conf. on Embedded 
Systems, June 12-16, Rochester, N.Y. Con¬ 
tact Lawrence P. Forsley, Inst, for Applied 
Forth Research, 70 Elmwood Ave., Rochester, 
NY 14611, phone (716) 235-0168, fax (716) 
328-6426, e-mail L.Forsley on Genie and 
LForsley on Bix and Delphi. 

IAPR Workshop on Syntactic and Struc¬ 
tural Pattern Recognition, June 13-15, Mur- 
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ray Hill, N.J. Sponsor: Int’l Assoc, for Pattern 
Recognition. Contact Henry S. Baird, AT&T 
Bell Laboratories, Rm. 2C-557, 600 Mountain 
Ave., Murray Hill, NJ 07974, phone (201) 582- 
5744. 

10th Int’l Symp. on Protocol Specification, 
Testing, and Verification, June 13-15, Ot¬ 
tawa, Ont., Canada. Sponsor: IFIP. Contact 
Luigi Logrippo, Computer Science Dept., 
Univ. of Ottawa, Ottawa, Ont., Canada KIN 
6N5. 


IA PR TC7 Workshop on Multisource Data 
Integration in Remote Sensing, June 14-15, 

College Park, Md. Cosponsors: Int’l Assoc, for 
Pattern Recognition, NASA Goddard Space 
Flight Center. Contact James C. Tilton, MC 
636, NASA Goddard Space Flight Center, 
Greenbelt, MD 20771, phone (301) 286-9510. 


Third Int'l Symp. on Image Conservation, 
June 17-20, Rochester, N.Y. Sponsor: Society 
for Imaging Science and Technology. Contact 
Charlton Bard, 74 Cornwall Lane, Rochester, 
NY 14617, phone (716) 342-3174. 


ffRh ICPR 90, 10th Int’l Conf. on Pattern 
Recognition, June 17-21, Atlantic City, 
N.J. Contact Herbert Freeman, CAIP Center, 
605 Hill, Rutgers Univ., New Brunswick, NJ 
08903, phone (201) 932-4208. 


Third IFIP Workshop on Geometric Model¬ 
ing, June 17-21, Rensselaerville, N.Y. Con¬ 
tact Mary Johnson, Rensselaer Design Re¬ 
search Center, Rensselaer Polytechnic Inst., 
Troy, NY 12180-3590, phone (518) 276-6751. 


IJCNN 90, 1990 Int’l Joint Conf. on Neural 
Networks, June 17-21, San Diego, Calif. Co¬ 
sponsors: IEEE, Int’l Neural Network Society. 
Contact Nomi Feldman, IJCNN, 5665 Oberlin 
Dr., Suite 110, San Diego, CA 92121. 


OTM EDFT, Seventh European Workshop 
on Design for Testability, June 18-20, 

Segovia, Spain. Contact T.W. Williams or C. 
Lopez Barrio, IBM, PO Box 1900, Dept. AJA/ 
02IB, Boulder, CO 80301-9191, phone (303) 
924-7692. 


IMSC 90, Int’l Mobile Satellite Conf., June 
18-20, Ottawa, Canada. Cosponsors: NASA, 
Canadian Dept, of Communications. Contact 
IMSC 90 Organizing Committee, c/o D. Hugh 
M. Reekie, Dept, of Communications, 300 
Slater St., Ottawa, Ont., Canada K1A 0C8. 

Workshop on Computer-Aided Verifica¬ 
tion, June 18-20, Princeton, N.J. Contact E.M. 
Clarke, Computer Science Dept., Carnegie 
Mellon Univ., Pittsburgh, PA 15213-3890; 
R.P. Kurshan, AT&T Bell Labs, Rm. 2C-353, 
Murray Hill, NJ 07974; A. Pnueli, Weizmann 
Inst., Rehovot, Israel; or J. Sifakis, LGI- 
IMAG, BP 53X, 38041 Grenoble Cedex, 

Seventh Int’l Conf. on Testing Computer 
Software, June 18-21, San Francisco. Contact 
Genevieve Houston-Ludlam, ISTC 90, c/o 
Frontier Technologies, 190 Admiral Cochran 


Dr„ Shite 180, Annapolis, MD 21401, phone 
(301) 266-8244. 

Second Int’l Conf. on Software Engineering 
and Knowledge Engineering, June 21-23, 

Skokie, Ill. Sponsors: Knowledge Systems 
Inst., Univ. of Pittsburgh, and Inst, for Infor¬ 
mation Industries, Taiwan. Contact Shi-Kuo 
Chang, Computer Science Dept., Univ. of 
Pittsburgh, 322 Alumni Hall, Pittsburgh, PA 
15260, phone (412) 624-8490. 


gapore. Sponsors: Computer Graphics Soci¬ 
ety, Inst, of Systems Science, Singapore. Con¬ 
tact Juzar Motiwalla, CGI 90, ISS, Nat’l Univ. 
of Singapore, Heng Mui Keng Terr., Kent 
Ridge, Singapore 0511, phone (65) 772-2075. 

1990 ACM Conf. on Lisp and Functional 
Programming, June 27-29, Nice, France. 
Contact Gillies Kahn, INRIA Sophia — An- 
tipolis, 2004 Route des Lucioles, 06565 
Valbonne Cedex, France, phone (33) 93-65- 
78-01. 


NECC 90, 11th Nat’l Educational Comput¬ 
ing Conf., June 25-27, Nashville, Tenn. Spon¬ 
sor: Int’l Council for Computers in Education. 
Contact John D. McGregor, Computer Studies 
Dept., Murray State Univ., Murray, KY 42071, 
phone (502) 762-2614. 

DAC 90, 27th ACM/IEEE Design 
Automation Conf., June 25-29, 

Orlando, Fla. Contact Pat Pistilli, MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boulder, 
CO 80301, phone (303) 530-4333. 

Int’l Symp. on Fuzzy Approach to Rea- 
soning and Decision Making, June 25- 

29, Bechyne, Czechoslovakia. Cosponsor: 

Int’l Fuzzy System Assoc. Contact Vilem No¬ 
vak, Minin Inst., Czechoslovakia Academy of 
Sciences, A. Rimana 1768, 70800 Ostrava- 
Poruba, Czechoslovakia. 

Advanced Research Workshop on 3D Imag¬ 
ing in Medicine, June 25-29, Travemuende, 
Federal Republic of Germany. Sponsor: 
NATO. Contact Linda Houseman, Computer 
Science Dept., Univ. of North Carolina, Box 
3175, Sitterson Hall, Chapel Hill, NC 27599, 
phone (919) 962-1758 (for the Americas); or 
Andreas Pommert, Inst, fur Mathematik und 
Datenverarbeitung in der Medizin, Univ. 
Krankenhaus Eppendorf, Martinistrasse 52, 
2000 Hamburg 20, Federal Republic of Ger¬ 
many, phone 49 (40) 468-2300 (for Europe, 
Asia, Australia, and Africa). 

EKAW 90, Fourth European Knowledge 
Acquisition for Knowledge-Based Systems 
Workshop, June 25-29, Amsterdam. Contact 
John H. Boose, Advanced Technology Center, 
Boeing Computer Services 7L-64, PO Box 
24346, Seattle, WA 98124, phone (206) 865- 
3253. 

FTCS 20, 20th Int’l Symp. on Fault- 
Tolerant Computing, June 26-28, 

Newcastle upon Tyne, England. Cosponsors: 
Centre for Software Reliability, British Com¬ 
puter Society, IEE. Contact Neil Speirs, Com¬ 
puting Lab, Univ. of Newcastle upon Tyne, 
Newcastle upon Tyne, NE1 7RU, UK, phone 
44 (91) 232-8511. 

Compass 90, Fifth Conf. on Computer As¬ 
surance: Systems Integrity, Software 
Safety, and Process Security, June 26-29, 

Gaithersburg, Md. Cosponsors: IEEE Aero¬ 
space and Electronics Society, IEEE Nat’l 
Capital Area Council. Contact Dolores Wal¬ 
lace, Nat’l Inst, of Standards and Technology, 
Gaithersburg, MD 20899; (301) 975-3340. 


Fifth Rocky Mountain Conf. on Artifi- 
cial Intelligence, June 28-30, Las 

Cruces, N.M. Cosponsors: ACM et al. Contact 
Paul McKevitt, Computing Research Lab, 
Dept. 3CRL, Box 30001, New Mexico State 
Univ., Las Cruces, NM 88003-0001, phone 
(505) 646-5109, fax (505) 646-6218, Internet 
paul@nmsu.edu. 


July 1990 


Roundtable Discussion on Vision-Based 
Vehicle Guidance, July 2, Tokyo. Sponsor: 
Committee of IEEE Int’l Workshop on Intelli¬ 
gent Robots and Systems. Contact Ichiro 
Masaki, Computer Science Dept., GM Re¬ 
search Labs, 30500 Mound Rd., Warren, MI 
48090-9055, phone (313) 986-1466. 

Second Int’l Symp. on Databases in 
Parallel and Distributed Systems, July 
2-4, Dublin, Ireland. Cosponsor: ACM. Con¬ 
tact Rakesh Agrawal, AT&T Bell Labs, Rm. 
3D450, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2250; or David Bell, 
Inst, of Informatics, Univ. of Ulster, Jordans- 
town, County Antrim, Northern Ireland 
BT370QB, phone (0232) 365-131. 

trQl Second Int’l Conf. on Economics and 
Artificial Intelligence, July 2-6, Paris. 
Sponsor: AFCET. Contact J-L. Le Moigne, 
GRASCE, Univ. Aix Marseille III, 3, ave. 
Robert Schuman, 13628, Aix en Provence, 
France; or P. Bourgine, 26, rue St. Louis, 
78000, Versailles, France. 

(jjj) SPAA 90, Second ACM Symp. on Par- 
allel Algorithms and Architecture, 
July 2-6, Crete, Greece. Cosponsor: ACM. 
Contact Tom Leighton, MIT, Cambridge, MA 
02139, phone (617) 253-3662. 

Fourth TC2 Working Conf. on Database 
Semantics, July 2-6, Windermere Lake Dis¬ 
trict, UK. Sponsor: IFIP, Coopers and Lybrand 
UK. Contact William Kent, Hewlett-Packard 
Labs, Dept. 3U, 1501 Page Mill Rd., Palo Alto, 
CA 94304-0971; or Robert Meersman, Info- 
lab, Tilburg Univ., PO Box 90153, 5000 LE 
Tilburg, The Netherlands. 

WCCE 90, Fifth World Conf. on Com- 
puters in Education, July 9-13, Syd¬ 
ney, Australia. Cosponsors: IFIP et al. Contact 
WCCE 90, PO Box 319, Darlinghurst, NSW 
2010, Australia, phone (612) 211-5855. 
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Fourth Annual Parallel Processing Symposium (IV APPS) 


Co-Sponsored by the IEEE Orange County Computer Society 
California State University Fullerton 

University Center April 4-6, 1990 

Calif State University Fullerton Wednesday-Thursday-Friday 

Fullerton, Ca 92634 8:30 am— 5:30 pm 


WEDNESDAY 

**Justin Rattner 
9:00-11:45 Director of Parallel 

Scientific Computing, Intel 
Parallel Architecture 

11:45-12:15 Neural Controllers 

’Kenneth Kreutz, UCSD 

Systolic Processing 
‘Tomas Lang, UCLA 

Multiprocessor Scheduling 
and Load Balancing 
*Nader Bagherzadeh, UCI 

1:30-3:00 Parallel Algorithms I 

’Mary Eshaghian, USC 

Neuroprocessing Devices 

*Anil Thakoor, JPL 

Commercial/Demo 
Neil Lochrie 
CSA 

3:30-5:00 Optical Neurocomputers 
*H.K. Liu, JPL 

Parallel Programming For 
Database and Knowledge 
Based Systems 

*Lubomir Bic 

Commercial/Demo 

Alex Williman, RI 


'Session Chairman 
"Keynote Speaker 


THURSDAY 

”Dr. Michael Zak 

Jet Propulsion Labs 

The Future of Neural Networks 

Parallel Programming Tools 
*Alex Nicolau, UCI 

Neurocomputers For Machine Vision 

*Teri Lawton, JPL 

Object Oriented Programming 
*David Falconer, CSUF 

Open-Potpourri 
*Alireza Kavinpour, UCI 

Parallel Architecture 

*V.K. Prasanna Kumar, USC 

Combinational Optimization 
*S.S. Iyengar, LSU 

Commercial/Demo 

Parallel Numerical Methods 
Amir Fijany, JPL 

Parallel Algorithms II 
*David Nassimi, NJIT 

Student Presentations 

Neural Network Theory 
’Victor Eliashberg, ULS Inc. 

Commercial/Demo 
George Westrum, Odetics 

TUTORIAL: PARALLEL 

PROCESSING 
1:00-5:00 Lubomir Bic/ 

Alex Nicolau UCI 


FRIDAY 

’’Prof. H.T. Rung 

Carnegie Mellon 
High-Performance Systems 

Electronic Neurocomputers 

’Jacob Barhen, JPL 

Signal and Image Processing Systems 

’David Shu, Hughes 

Distributed Systems 

’Doug Blough, UCI 


Fault Tolerant Systems 
*C.S. Raghavendra, USC 

Multi-Processor Systems I 

’Magdy Bayoumi, USWL 

Commercial/Demo 


Early Registration: Before March 16, 1990 

Computer Society/IEEE/ACM: $125 or $50/day. 
Non-Members $175 all or $65/day. 

Full Time Students $15 all or $5/day. 
Proceedings $55 

Tutorial Early Registration Fee $100 
Before March 16, 1990 


Addre: 


Registration: After March 1990 

Computer Society/IEEE/ACM: $150 or $75/day. 
Non-Members $200 all or $85/day. 

Full Time Students $25 all or $10/day. 
Proceedings $65 
Tutorial Registration Fee $125 
After March 16, 1990 


Company - 

Company Tel. # 


Home Telephone - 

Affiliate: IEEE Computer/IEEE/ACM: Member #: - 

Fee Enclosed: Circle: Apr 4 Apr 5 Apr 6 

Make checks payable to: OC IEEE Parallel Processing Symposium 


General Chairman: 

Larry Canter, CSA 
Technical Co-Chairpersons: 
Nadar Bagherzadeh, UCI 
Sandeep Gulati, JPL 
Programm Committee Chairman 
V.K. Prasanna Kumar, USC 
Conference Consultant 
Howard Jelinek, EDA 
Commercial Session Chairman 
Alex Williman, RI 
Campus Coordinator 
Michael Singh, CSLB 
Staff Coordinator, Cal Poly, 
Pomona 
Corrinne Yu 


Mail Check To: Computer Systems Approach, Inc. 

1140 S. Raymond Av„ Suite B 
Fullerton, CA 92631 
(714) 738-3414 
(714) 738-3470 FAX 


For Hotel Accommodations 
CALL: MARRIOTT HOTEL 

2701 E. Nutwood Ave. 
Fullerton, CA 92631 
(714) 738-7800 
(800) 228-9290 
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ico. Sponsors: Centro Regional de Ensenanza 
en Informatica (Spain) et al. Contact Iberamia 
90, Atn. Srita. Ma. Antonieta Alvarez Perez, 
Apartado Postal 70302, C.P. 04510, Mexico . 


Int’l Neural Network Conf., July 9-13, Paris. 
Sponsors: IEEE Neural Networks Council, 
Int’l Neural Network Society. Contact Nina 
Thellier, NTC, 19, rue de la Tour, 75116 Paris 
Cedex, France, phone (33) 45-25-65-65, fax 
(33) 45-25-24-22. 


/£|j\ Third Int'l Conf. on Industrial and 
Engineering Applications for AI and 
Expert Systems, July 15-18, Charleston, S.C. 
Cosponsors: ACM et al. Contact Moonis Ali, 
Univ. of Tennessee Space Inst, MS 15, Tulla- 
homa, TN 37388, phone (615) 455-0631. 


1990 Summer Computer Simulation Conf., 
July 16-18, Calgary, Alta., Canada. Sponsor: 
Society for Computer Simulation. Contact 
SCS, PO Box 17900, San Diego, CA 92117- 
7900, phone (619) 277-3888. 

ICALP 90, 17th Int’l Colloquium on Auto¬ 
mata, Languages, and Programming, July 
16-20, Coventry, England. Sponsor: Int’l 
Computers, Ltd. Contact Computer Science 
Dept., Univ. of Warwick, Coventry CV4 7AL, 
UK, phone 44 (203) 523-194. 


Int’l Workshop on Semantics for Concur¬ 
rency, July 23-25, Leicester, UK. Sponsor: 
British Computer Society. Contact Marta 
Kwiatowska, Workshop on Semantics for 
Concurrency, Computing Studies Dept., Univ. 
of Leicester, Leicester LEI 7RH, UK, phone 
(44) 533-523603. 


Int’l Workshop on Principles of Diagnosis, 
July 23-25, Menlo Park, Calif. Cosponsors: 
American Assoc, for Artificial Intelligence, 
Price Waterhouse. Contact Walter Hamscher, 
Price Waterhouse Technology Center, 68 Wil¬ 
low Rd„ Menlo Park, CA 94025, phone (415) 
688-6669, e-mail hamscher@pw.com. 


10th Int’l Conf. in Computer Science, July 
23-27, Santiago, Chile. Contact Joachim von 
zur Gathen, Computer Science Dept., Univ. of 
Toronto, 10 King’s College Rd., Toronto, Can¬ 
ada M5S 1A4, phone (416) 978-6024, e-mail 
gathen@theory.toronto.edu. 

DIAC 90, Directions and Implications of 
Advanced Computing, July 28, Boston. 
Sponsor: Computer Professionals for Social 
Responsibility. Contact Douglas Schuler, 
Boeing Computer Services, MS 7L-64, PO 
24346, Seattle, WA 98124-0346, phone (206) 
634-2771. 

AAAI 90 Workshop of the Nat’l Conf. on AI, 
July 31-Aug. 3, Boston. Sponsor: American 
Assoc, for Artificial Intelligence. Contact Ed¬ 
ward Lafferty, AI Center, Mitre, MS A350, 
Burlington Rd., Bedford, MA 01730, phone 
(617) 271-2773. 


August 1990 

SIGComm 90 Conf., Aug. 1-5, Philadelphia. 
Sponsor: ACM SIGComm. Contact Phil Kam, 


Bell Communications Research, MS 2P-357, 
445 South St., PO Box 1910, Morristown, NJ 
07962-1910, phone (201) 829-4299. 

SIGGraph 90, 17th Conf. on Com- 
puter Graphics and Interactive Tech¬ 
niques, Aug. 6-10, Dallas. Sponsor: ACM. 
Contact Assoc, for Computing Machinery, 11 
W. 42nd St., New York, NY 10036, phone 
(212) 869-7440. 

16th Int’l Conf. on Very Large Data 
Bases, Aug. 13-16, Brisbane, Australia. 
Contact David Reiner, Lotus Development, 1 
Canal Park, Cambridge, MA 02141, phone 
(617) 577-8500. 

ICPP 90,19th Int’l Conf. on Parallel Pro¬ 
cessing, Aug. 13-17, St. Charles, Ill. Sponsor: 
Pennsylvania State Univ. Contact Tse-yun 
Feng, EE East Bldg., Pennsylvania State Univ., 
University Park, PA 16802, phone (814) 863- 


September 1990 


ISPRS Commission V Symp., Close- 

Range Photogrammetry Meets Ma¬ 
chine Vision, Sept. 3-7, Zurich. Cosponsor: 
Int’l Society for Photogrammetry and Remote 
Sensing et al. Contact Armin Gruen, Inst, of 
Geodesy and Photogrammetry, ETH- 
Hoenggerberg, CH-8093, Zurich, Switzer¬ 
land, phone 41 (1) 377-3051. 

First European Working Conf. on 

VHDL Methods, Sept. 4-7, Marseille, 
France. Cosponsors: ACM et al. Contact Petra 
Michel, Siemens, A.G. Dept. ZFE ISEA1, Otto 
Hahn Ring 6, Munich 83, West Germany. 

ASAP 90, Int’l Conf. on Application¬ 
's^ Specific Array Processors, Sept. 5-7, 

Princeton, N.J. Cosponsor: Princeton Univ. 
Contact S.Y. Kung, Electrical Engineering 
Dept., Princeton Univ., Princeton, NJ 08544, 
phone (609) 258-3780. 

ITC 90, Int’l Test Conf., Sept. 10-12, 

Washington, DC. Cosponsor: IEEE 
Philadelphia Section. Contact Donald 
Denburg, AT&T Bell Labs, 1247 S. Cedar 
Crest Blvd., Allentown, PA 18103; or ITC, 
1201 Sussex Turnpike, Suite 101, PO Box 264, 
Mt. Freedom, NJ 07970, phone (201) 895- 
5260. 

IEEE Conf. on Managing Expert Sys- 

tern Programs and Projects, Sept. 10- 

12, Washington, DC. Sponsor: IEEE Com¬ 
puter Society Technical Committee on Expert 
Systems. Contact Jay Liebowitz, Management 
Sciences Dept., George Washington Univ., 
Washington, DC, phone (202) 994-6969. 

ICCD 90, IEEE Int’l Conf. on Com- 
N57 puter Design: VLSI in Computers and 
Processors, Sept. 16-19, Cambridge, Mass. 
Contact Edward M. Middlesworth, Hewlett- 
Packard, Bldg. 25U, PO Box 10350, Palo Alto, 
CA 94303-0867, phone (415) 857-5485; or 


ICCD 90, IEEE Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

(£3^ ASIC 90, Third IEEE ASIC Seminar 

and Exhibit, Sept. 17-21, Rochester, 
N.Y. Cosponsors: IEEE Rochester Section, 
ACM. Contact Kenneth Hsu, Rochester Inst, of 
Technology, Computer Engineering Dept., 
Rochester, NY 14623, phone (716) 475-2655; 
or Lynne Engelbrecht, 170 Mt. Read Blvd., 
Rochester, NY 14611, phone (716) 328-2310, 
fax (716) 436-9370. 

EP 90, Electronic Publishing 90, Sept. 
vS? 18-20, Gaithersburg, Md. Sponsor: Nat’l 
Inst, of Standards and Technology. Contact Pe¬ 
ter R. King, Computer Science Dept., Univ. of 
Manitoba, Winnipeg, Man., Canada R3T 2N2, 
phone (204) 474-9935. 

Computational Intelligence 90, Sept. 

27-29, Milano, Italy. Sponsors: F.I.S. 
Cassa di Rosp. o. PC. Contact Giorgio Valle, 
Universita Milano. Dip. Scienze Della Infor- 
mazione. Via Noretto 20133, Milano, Italy. 

Future Trends 90, Workshop on Fu- 
nS? ture Trends of Distributed Computing 
Systems, Sept. 30-Oct. 2, Cairo. Contact 
Stephen S. Yau, Univ. of Florida, CIS Dept., 
Rm. 301, Gainesville, FL 32611, phone (904) 
335-8006. 


October 1990 


15th Conf. on Local Computer Net- 
working, Oct. 1-3, Minneapolis, Minn. 
Contact Marc Cohn, Advanced Development 
Div., Raychem Corp., 300 Constitution Dr., 
Menlo Park, CA 94025-1164, phone (415) 
361-3902, fax (415) 361-6099. 

lnfojapan 90, Int’l Conf. on Informa- 
tion Technology, Oct. 1-5, Tokyo. 
Sponsor: IPSJ. Contact Takuma Yamamoto, 
Fujitsu, 3-14-1 Hiyoshi, Kohoku-ku, Yokoha- 
mashi, Japan. 

Sixth Int’l Conf. on the Application of 
Standards for Open Systems Intercon¬ 
nection, Oct. 2-4, Gaithersburg, Md. Cospon¬ 
sor: Nat’l Inst, of Standards and Technology. 
Contact Brenda Gray, NIST/OSI, Rm. B217, 
Bldg. 225, Gaithersburg, MD 20899, phone 
(301) 975-3664. 

Frontiers 90, Third Symp. on Fron- 
viy tiers of Massively Parallel Computa¬ 
tion, Oct. 8-10, College Park, Md. Cosponsor: 
NASA Goddard Space Flight Center. Contact 
Johanna Weinstein, Frontiers 90, UMIACS, 
Univ. of Maryland, A.V. Williams Bldg., Col¬ 
lege Park, MD 20742, phone (301) 454-1808. 

Ninth Symp. on Reliable Distributed 
nSz Systems, Oct. 9-11, Huntsville, Ala. 
Contact Raif M. Yanney, TRW, MS DH2/ 
2328, 1 Space Park, Redondo Beach, CA 
90278, phone (213) 764-6033. 
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SOCIETY 


The Awards Committee of the 
IEEE Computer Society 
solicits nominations for the 
following key society awards: 


ECKERT-MAUCHLY AWARD 

Awarded jointly by the ACM and the Computer Society for outstanding 
contributions to the field of computer architecture. 

IV. WALLACE MCDOWELL AWARD 

Outstanding recent theoretical, design, educational, practical, or other innovative 
contributions to computer science and engineering. 

TECHNICAL ACHIEVEMENT AWARD 

Outstanding and innovative contributions to the field of computer science or 
computer technology within the past 15 years. 

COMPUTER ENTREPENEUR AWARD 

Managers whose vision and leadership have resulted in growth of some segment 
of the computer industry. Contributions shall have occurred at least 15 years ago. 

RICHARD E. MERWIN DISTINGUISHED SERVICE AWARD 

Highest service award granted by the Computer Society, in recognition of 
outstanding service to the profession at large, including service to the 
Computer Society or its predecessor organizations. Nominee must be a 
Computer Society member. 


TAYLOR BOOTH AWARD 


Recognizes individuals for their outstanding record in computer science and 
engineering. Criteria include achieving recognition as a teacher of reknown in a 
relevant course; writing an influential text in computer science and engineering; 
leading, inspiring, or providing significant educational content during the creation 
of a curriculum in the field; and inspiring others to a career in computer science 


and engineering education. 


Deadlines: Nomination deadline for all awards: September 15. Send a letter giving details and any supporting 
documentation to the Awards Committee chairman: 


Joseph E. Urban 

Department of Computer Science 
Arizona State University 
Tempe, Arizona 85287-5406 
Compmail: J.Urban 
E-mail: jurban@enuxha.eas.asu.edu 



IEEE COMPUTER SOCIETY 



THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC. 










Contact Rachel Rusting, Intermetrics, 733 
Concord Ave., Cambridge, MA 02138, phone 
(617) 661-1840. 

OOPSLA 90, Fifth Conf. on Object- 
\S& Oriented Programming Systems, Lan¬ 
guages, and Applications, Oct. 21-25, Ot¬ 
tawa, Canada. Cosponsor: ACM. Contact As¬ 
soc. for Computing Machinery, 11 W. 42nd St., 
New York, NY 10036, phone (212) 869-7440. 

FOCS, 31st Foundations of Computer 
Science, Oct. 22-24, St. Louis, Mo. Con¬ 
tact Christos Papdimitriou, Computer Science 
Dept., Univ. of California at San Diego, La 
Jolla, CA 92093, phone (619) 534-2086. 

4(j)} JC1T 5, Fifth Jerusalem Conf. on In- 
formation Technology, Oct. 22-25, 
Jerusalem, Israel. Sponsor: Information Pro¬ 
cessing Assoc, of Israel. Contact Abraham 
Peled, IBM T.J. Watson Research Center, PO 
Box 704, Yorktown Heights, NY 10598. 

Visualization 90, Oct. 23-26, San Fran- 
cisco. Contact Bruce Brown, Oracle 
Corp., 20 Davis Dr., Belmont, CA 94002, 
phone (415) 598-3628. 

/gfjb NACLP 90, 1990 North American 

Conf. on Logic Programming, Oct. 28- 
Nov. 1, Austin, Texas. Cosponsor: ACM. Con¬ 
tact Carlo Zaniolo, MCC, 3500 W. Balcones 
Center Dr., Austin, TX 78759, phone (512) 
338-3442. 

Compsac 90, 14th Int’l Computer 
Software and Applications Conf., Oct. 
31-Nov. 2, Chicago. Contact Ifay F. Chang, 
Rm. 1B28, IBM T.J. Watson Research Center, 
PO Box 714, Yorktown Heights, NY 10595, 
phone (914) 789-7825. 


November 1990 


ating Systems. Contact Jehan-Francois Paris, 
Computer Science Dept., Univ. of Houston, 
Houston, TX 77204-3475, phone (713) 749- 
3943, e-mail paris@cs.uh.edu; Luis-Felipe 
Cabrera, IBM Almaden Research Center, 650 
Harry Rd„ MC K55/803, San Jose, CA 95120- 
6099, phone (408) 927-1838. 

ICCAD 90, IEEE Int’l Conf. on Com- 

puter-Aided Design, Nov. 11-15, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Society. Contact Pat Pistilli, MP As¬ 
sociates, 7490 Clubhouse Rd., Suite 102, Boul¬ 
der, CO 80301, phone (303) 530-4562 or 4333. 

Supercomputing 90, Nov. 12-16, New 

York City. Cosponsor: ACM. Contact 
Joanne L. Martin, IBM T.J. Watson Research 
Center, PO Box 218, Route 134, Yorktown 
Heights, NY 10698, phone (914) 945-3285; or 
Supercomputing 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

Cognitiva 90, Nov. 20-23, Madrid. 

Sponsor: AFCET. Contact Cognitiva 90, 
c/o AFCET, 156 Bd Pereire, 75017 Paris, 
France, phone 33 (01) 47-66-24-19. 

IEEE 1990 Conf. on Software Mainte- 
V&7 nance, Nov. 26-29, San Diego, Calif. 
Contact Thomas M. Pigoski, USN, NSGD 
Pensacola, Corry Station, Pensacola, FL 
32511, phone (904) 452-6399. 

Micro 23, 23rd Symp. and Workshop 

on Microprogramming and Micro¬ 
architecture, Nov. 27-29, Orlando, Fla. Co¬ 
sponsor: ACM. Contact Chris Papachristou, 
Case Western Reserve Univ., Computer Engi¬ 
neering and Science Dept., Cleveland, OH 
44106, phone (216) 368-5277, e-mail 
cap@alpha.ces.cwru.edu. 


December 1990 


14th SCAMC, 1990 Symp. on Com- 
'SS puter Applications in Medical Care, 
Nov. 4-7, Washington, DC. Cosponsors: 
George Washington Univ. Medical Center et 
al. Contact SCAMC — Office of CEM, George 
Washington Univ. Medical Center, 2300 K St. 
NW, Washington, DC 20037, phone (202) 
994-8928. 

Igfjl Intelligent Robotic Systems; Design 
and Applications, Nov. 6-7, Philadel¬ 
phia. Sponsor: SPIE. Contact Mohan M. Tri- 
vedi, Univ. of Tennessee, Electrical and Com¬ 
puter Engineering, Ferris Hall, Knoxville, TN 
37996-2100, phone (615) 974-5450. 

TAI 90, Second Computer Society 
Int’l Conf. on Tools for Artificial Intel¬ 
ligence, Nov. 6-9, Washington, DC. Cospon¬ 
sors: Rutgers Univ. et al. Contact Nikolas G. 
Bourbakis, George Mason Univ., ECE Dept., 
Fairfax, VA 22030, phone (703) 425-3930. 

IEEE Workshop on the Management 
of Replicated Data, Nov. 7-9, Houston. 
Sponsor: IEEE Technical Committee on Oper- 


Contact ICCV 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

11th Real-Time Systems Symp., Dec. 

5-7, Orlando, Fla. Sponsor: IEEE Com¬ 
puter Society Technical Committee on Real- 
Time Computing. Contact Doug Locke, IBM 
— MS 409, Systems Integration Div., 6600 
Rockledge Dr., Bethesda, MD 20817, phone 
(301) 493-1496, e-mail cdl@cs.cmu.edu. 

CASE 90, Fourth Int’l Workshop on 

Computer-Aided Software Engineer¬ 
ing, Dec. 5-8, Irvine, Calif. Contact Elliott J. 
Chikofsky, Radius Systems, 75 Lexington St., 
Burlington, MA 01803, phone (617) 494- 


San Diego Workshop on Volume Visu- 
alization, Dec. 10-11, La Jolla, Calif. 
Cosponsor: ACM. Contact T. Todd Elvins, 
SDSC, Box 85608, San Diego, CA 92038, 
phone (619) 534-5128. 

Second IEEE Symp. on Parallel and 
Distributed Processing, Dec. 10-12, 

Dallas. Sponsor: Dallas Section of the IEEE 
Computer Society. Contact Behrooz Shirazi, 
Computer Science and Engineering Dept., 
Southern Methodist Univ., Dallas, TX 75275, 
phone (214) 692-2874, e-mail shirazi%smu.uu 
cp@uunet.uu.net. 

1990 IEEE Workshop on Languages 
and Architectures for Automation, 
Dec. 19-21, Honolulu, Hawaii. Sponsors: Pa¬ 
cific Inf 1 Center for High Technology Re¬ 
search et al. Contact D.Y.Y. Yun, Univ. of Ha¬ 
waii, 711 Kapiolani Blvd., Suite 200, Hono¬ 
lulu, HI 96813-5249, phone (808) 539-1532, 
fax (808) 941-1399; or Shi-Kuo Chang, 322 
Alumni Hall, Univ. of Pittsburgh, Pittsburgh, 
PA 15260, phone (412) 624-8493, fax (412) 
624-8465, e-mail chang@vax.cs.pitt.edu. 


January 1991 


gTO First Inf I Symp. on Uncertainty and 
Analysis: Fuzzy Reasoning, Probabil¬ 
istic Methods, and Risk Management, Dec. 
3-5, College Park, Md. Sponsors: Univ. of 
Maryland et al. Contact Bilal M. Ayyub, Civil 
Engineering Dept., Univ. of Maryland, Col¬ 
lege Park, MD 20742. 

ACM SIGSoft 90, Fourth Symp. on 
Software Development Environ¬ 
ments, Dec. 3-5, Irvine, Calif. Sponsor: ACM. 
Contact Dewayne E. Perry, AT&T Bell Labs, 
600 Mountain Ave., Murray Hill, NJ 07974, 
phone (201) 582-2529. 

{Qjt Sixth Computer Security Applica¬ 
nt^ tions Conf., Dec. 3-7, Tucson, Ariz. 
Sponsors: American Society for Industrial Se¬ 
curity et al. Contact Marshall D. Abrams, Mitre 
Corp., 7525 Colshire Dr., M/S Z269, McLean, 
VA 22101, phone (703) 883-6938, e-mail 
abrams@mitre.org. 

(gfc ICCV 90, Third Inf I Conf. on Com- 
' puter Vision, Dec. 4-7, Osaka, Japan. 


yr>l Inf I Conf. on Multimedia Informa¬ 
nts tion Systems, Jan. 16-18, Singapore. 
Contact Juzar Motiwalla, Inst, of Systems Sci¬ 
ence, Nat’l Univ. of Singapore, Heng Mui 
Keng Terr., Kent Ridge, Singapore 0511, 
phone (65) 772-2075. 


February 1991 

CAIA 91, Seventh IEEE Conf. on Arti- 
n=s ficial Intelligence Applications, Feb. 
24-28, Miami Beach, Fla. Contact IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

Com peon Spring 91, Feb. 25-Mar. 1, 

n=s San Francisco. Contact Compcon Spring 
91, IEEE Computer Society, 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 
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IEEE TRANSACTIONS ON 

PARALLEL AND 
DISTRIBUTED SYSTEMS 

JANUARY 1990 VOLUME 1 NUMBER 1 PREMIERE ISSUE 

A PUBLICATION OF THE IEEE COMPUTER SOCIETY 


GENERAL AREA ADDRESSED 

Hardware/software issues and applications studies specifically for parallel and/or distributed systems. 


FIRST ISSUE: January 1990 FREQUENCY: Quarterly 

SCOPE: 

Hardware/software issues and applications studies specifically for parallel and/or distributed systems. 


SAMPLE SUBJECT AREAS: 

Parallel and distributed architectures — Design, analysis, and implementation of multiple-processor systems; 
impact of VLSI on parallel/distributed design; inter-processor/memory communications. 

Parallel and distributed software — Parallel languages and compilers; scheduling and task partitioning; 
databases in parallel/distributed systems. 

Parallel algorithms and applications — Parallel models of computation; analysis and design of parallel 
numeric/non-numeric algorithms; applications studies using parallel/distributed systems. 

Other issues — Performance measurements, evaluation, modeling and simulation of parallel/distributed 
architectures; reliability and fault-tolerance issues concerning parallel/distributed systems. 


SIGN ME UP! 

for Transactions on Parallel and Distributed Systems 

n I’m a member of the IEEE Computer Society, so bill me for the 
member rate of $11 for a year (four issues) or after February 28, 
a half-year (two issues) for $5.50. 

IEEE Member Number: _ 

n I’m not a member of the IEEE Computer Society, but I am a member 
of another professional organization, so bill me at the sister society 
rate of $20 for a year (four issues). 

The professional organization I belong to that 
qualifies me for this rate is _ 

□ Payment enclosed □ Bill me 

□ Credit card : □ AmEx □ Mastercard □ Visa 
(Minimum Charge $10.00) 

Credit card #:_ | 

Signature: _ 

Name_ 

Address_ 

City_ I 

State_ Postal Code _Country_ 

OFFER EXPIRES AUGUST 31, 1990 C om P 3/90j 


To order your subscription 
to IEEE Transactions on 
Parallel and Distributed 
Systems, send the coupon at 
right to IEEE Computer 
Society, Membership 
Department, 10662 Los 
Vaqueros Circle, PO Box 
3014, Los Alamitos, CA 
90720-1264. You may also 
call (714) 821-8380 or fax it 
to us at (714) 821-4010 and 
charge it to your 
MasterCard, Visa, or 
American Express Card. 
(Minimum Charge $10.00) 

































CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“...recent college grads...,” “...1-4 years 
maximum experience...,” “...up to5 years 
experience...,” or “...10 years maximum 
experience.” COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


RUTGERS UNIVERSITY 

The Department of Computer Science at 
Rutgers, The State University of New Jersey, 
invites applications for tenure-track faculty 
positions at both the junior and senior levels. 
Particularly sought are individuals pursuing 
research in Systems and Artificial Intelli¬ 
gence, although candidates in other areas 
will also be considered. 

The department has a mature graduate 
program, with an excellent pool of almost 
300 MS and PhD students, in addition to an 
undergraduate program leading to a Bache¬ 
lor’s degree. There are over 30 full time 
faculty members, with major strength in 
areas such as Algorithms and Theoretical 
Computer Science, Artificial Intelligence, 
Combinatorial Optimization, Numerical 
Analysis Database and Software Systems. 
Located in the New York City-Philadelphia 
corridor, Rutgers offers excellent opportu¬ 
nities for cultural activities and close profes¬ 
sional contact with nearby major research 
laboratories and other leading universities. 

An applicant should have a Ph.D. or ex¬ 
pect it within a short time, and should be 
committed to excellence in research and 
teaching. Send curriculum vitae, including 
the names and addresses of three refer¬ 
ences, and copies of recent papers to Prof. I. 
Rabinowitz, Chair of Faculty Search Com¬ 
mittee, Department of Computer Science, 
Hill Center, Rutgers University, New Bruns¬ 
wick, NJ 08903. Rutgers is an Affirmative 
Action/Equal Opportunity Employer. 


UNIVERSITY OF PITTSBURGH 
AT JOHNSTOWN 

Applications are invited for a tenure-track 
position anticipated in the Computer Sci¬ 
ence Department, beginning August 1990. 
The appointment will be for an Assistant Pro¬ 
fessor but other ranks will be considered. 
Preference is for broad CS experience; how¬ 
ever, candidates should expect to perform 
teaching assignments in Assembler, Data 
Structures, Numerical Analysis, Algorithm 
Analysis, and service courses on occasion. 
The opportunity exists to grow into other 
areas as well. Experience with UNIX is 
essential. The salary is negotiable depending 
upon qualifications and experience. Appli¬ 
cations will be accepted from Qualified 
Master’s degree holders, but preference will 
be given to applicants holding the Ph.D. in 
computer science or a closely related area. 

UPJ expects its computer science faculty 
to maintain high quality teaching and advis¬ 
ing, to continue to develop professionally, to 
become involved in campus affairs, and to 
show initiative in supervising undergraduate 
student projects in such areas as expert sys¬ 
tems, computer graphics, data base systems, 
and software engineering. 

Application deadline: March 15, 1990, or 
later until the positon is filled. 

Applicants should submit a curriculum 
vitae and a cover letter describing their recent 
experience and how it relates to candidacy 
for this position. Candidates should also sub¬ 
mit the name of three referees. AH corre¬ 
spondence should be directed to: 

Mrs. Patricia Hagerich 
CS Search Coordinator 
Associate Professor 
ES221 

University of Pittsburgh at Johnstown 
Johnstown, PA 15904 
UPJ is an EO/AA Employer. 


TRINITY COLLEGE 

The Department of Engineering and Com¬ 
puter Science announces a tenure-track 
position, pending approval, in the field of 
Mechanical Engineering. It, therefore, in¬ 
vites applications from outstanding candi¬ 
dates for a position at the Assistant or 
Associate Professor-level commencing Sep¬ 
tember, 1990, in the areas of THERMO¬ 
DYNAMICS/HEAT TRANSFER or ROBOT¬ 
ICS/CONTROLS. Experimental background 
highly desirable. The position involves grad¬ 
uate and undergraduate instruction and 
research, and a doctoral degree is a prereq¬ 
uisite. We are interested in receiving applica¬ 
tions from women and minorities. Trinity 
College is an equal opportunity/affirmative 
action employer. Please send resume to Pro¬ 
fessor Joseph D. Bronzino, Chairman, ECS 
Department, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin immediately and the search will remain 
open until the position is filled. 


AVIATION COMPUTER SCIENCE 
DEPARTMENT FACULTY POSITIONS 

Applications are invited for full-time 
tenure track faculty positions. Either a Ph.D. 
in Computer Science or a Ph D. in a closely 
related field with a Master’s degree in Com¬ 
puter Science is required. We are seeking 
experienced computer science professionals 
as well as new graduates to assist with the 
continued development of an innovative 
undergraduate program emphasizing avia¬ 
tion as the domain of application. Candi¬ 
dates should have an interest in one of the 
areas of computer modeling and simulation, 
artificial intelligence, real time systems, or 
software engineering. Rank will be commen¬ 
surate with qualifications and experience, 
and salary will be competitive. 

The department offers a B.S. in Aviation 
Computer Science which follows ACM cur¬ 
riculum guidelines as well as emphasis on 
aviation systems. Facilities include an IBM 
4361, numerous microcomputers and a mic¬ 
roprocessor lab. The department is develop¬ 
ing a research plan and faculty with research 
potential will be given preference. Please sub¬ 
mit a resume and the names of three refer¬ 
ences to: Dr. Iraj Hirmanpour, Chair, 
Faculty Search Committee, c/o Human 
Resources Department, Embry-Riddle 
Aeronautical University, Daytona 
Beach, FL 32114-3900. EOE. 


COLORADO SCHOOL OF MINES 
Golden, Colorado 
Computer Scientist 

The Colorado School of Mines Depart¬ 
ment of Mathematics invites applications for 
a tenure-track faculty position in Computer 
Science. This program emphasizes software 
development, software systems, artificial in¬ 
telligence, languages, database manage¬ 
ment, and numerical computation. Speciali¬ 
zation in software engineering is desired but 
consideration will be given to applications 
with experience in all areas of program 
emphasis. 

Duties include teaching and graduate stu¬ 
dent research supervision. Applicants should 
demonstrate significant research accom¬ 
plishment or exceptional research promise 
and a commitment to excellence in teaching. 
Record of funded research should be docu¬ 
mented by applicants for a senior level posi¬ 
tion. A Doctorate in a computer-related field 
required. Departmental programs in mathe¬ 
matical and computer sciences. 

Applications will be accepted until such 
time as the position is filled. 

Send vita including publications and 
names of three (3) references to: 

COLORADO SCHOOL OF MINES 

Computer Science Search Committee 

PO Box 69 

Golden, CO 80401 

An Equal Employment/Affirmative Ac¬ 
tion Employer. Females and Minorities En¬ 
couraged to Apply. 


124 


COMPUTER 















UNIVERSITY OF VERMONT 
Visiting Faculty Positions 
in Computer Science 

The Department of Computer Science 
and Electrical Engineering invites applica- • 
tions for up to two visiting faculty openings in 
Computer Science, commencing Septem¬ 
ber, 1990. A doctorate in Computer Sci¬ 
ence, or the equivalent is required. The level 
of assistant or associate professor will be 
dependent upon the candidates’ qualifica¬ 
tions. Responsibilities, in addition to re¬ 
search , include teaching in mainstream com¬ 
puter science at both the undergraduate and 
graduate level in two or more of the following 
areas: operating systems, programming lan¬ 
guages, database systems, computational 
complexity and algorithm theory, theory of 
computation, as well as the presentation of 
an advanced graduate course or seminar. 
Applications will be accepted until the posi¬ 
tions are filled. Please submit a resume, in¬ 
cluding teaching experience, a publication 
list, and the names, addresses, and phone 
numbers of three references to: Dr. Kenneth 
Golden, Chairperson; University of Ver¬ 
mont; Department of Computer Science 
and Electrical Engineering; Votey Building; 
Burlington, VT 05405; (802) 656-3330. In¬ 
ternet & CSnet: cssearch@uvm.edu;USE- 
NET: . . ,uunet!uvm-gen!cssearch;BITNET: 
cssearch@uvm-gen.uvm.edu. The Univer¬ 
sity of Vermont is an Affirmative Action 
Equal Opportunity Employer and encour¬ 
ages applications from women and members 
of minority groups. 


MISSISSIPPI STATE UNIVERSITY 
Head, Department of 
Computer Science 

Mississippi State University invites applica¬ 
tions and nominations for the position of 
head of the Department of Computer Sci¬ 
ence. A successful candidate must have (1) 
an earned doctorate in computer science or 
related field, and (2) faculty experience in a 
doctoral granting program. In addition, can¬ 
didates should have demonstrated leader¬ 
ship and a successful record of teaching, 
research, and grant procurement. The ap¬ 
pointment will be at the rank of professor 
with a highly competitive salary. The an¬ 
ticipated starting date is July 1, 1990. 

As one of the 100 largest research univer¬ 
sities (expenditures) in the country and the 
largest university in the state, MSU offers a 
broad range of undergraduate and graduate 
programs. The Department of Computer 
Science offers a CSAB-accredited under¬ 
graduate program and graduate study lead¬ 
ing to the MCS, MS and PhD degrees. In co¬ 
operation with electrical engineering, the 
department also offers programs of study 
leading to the BS and MS degrees in com¬ 
puter engineering. 

Screening of candidates will begin Febru¬ 
ary 15, 1990 and will continue until the posi¬ 
tion is filled. Nominations and applications 
with curriculum vita should be sent to: Dr. 
George S. Rent, Chairperson, Search Com¬ 
mittee for Head of Computer Science, Col¬ 
lege of Arts and Sciences, P.O. Box AS, 
Mississippi State, MS 39762. MSU is an equal 
opportunity affirmative action employer. 


UNIVERSITY OF WISCONSIN- 
MADISON 
Faculty Positions 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
tenure and tenure-track positions. A Ph D. 
degree is required, and successful candi¬ 
dates are expected to participate in both 
teaching and research activities. Applicants 
in all areas of computer engineering are in¬ 
vited to apply, but the following areas are of 
special interest: computer architecture, com¬ 
puter networks, VLSI and computer-aided 
design, microprocessor and minicomputer 
applications, real-time control and instru¬ 
mentation applications, and engineering ap¬ 
plications of artificial intelligence. Rank and 
salary will be commensurate with qualifica¬ 
tions and experience. Send resume and 
names of three references to J. Leon 
Shohet, Chairman, Department of Electrical 
and Computer Engineering, University of 
Wisconsin-Madison, 1415 Johnson Drive, 
Madison, WI 53706, an equal opportunity/ 
affirmative action employer. 


FOOTHILL-DE ANZA 
COMMUNITY COLLEGE 
Computer Sciences Instructor 

Provide classroom instruction in both basic 
and advance computer sciences courses in 
the transfer and vocational curriculum. Areas 
of instruction include, but not limited to, 
Algorithms, Data Structures, basic computer 
architecture and programming, Pascal, C/ 
Unix, Lisp, and Assemble, Assist in the 
organization of the computer science cur¬ 
riculum and laboratories; and assist in the ac¬ 
quisition of hardware and software. Maintain 
a flexible attitude toward different teaching 
methodologies. Remain current profession¬ 
ally and help create links with the scientific, 
technical, business, and academic commun¬ 
ities. Education and experience require¬ 
ments along with an application and com¬ 
plete job description may be obtained from: 
Employment Services, Foothill-De Anza 
Community College District, 12345 El 
Monte Road, Los Altos Hills, CA 94022. 
(415) 949-6217. A resume or vita may not 
be substituted for a completed application. 
Deadline for application 3/21/90. AA/EOE. 


TEXAS A&M UNIVERSITY 
Endowed Chair 
in Software Engineering and 
Parallel Computation Systems 

Texas A&M University invites nomination 
of qualified individuals for an endowed chair 
in software engineering and parallel compu¬ 
tation systems, with specialization in any of 
the related areas. Candidates should have 
outstanding professional and personal qual¬ 
ifications, including national and interna¬ 
tional recognition for their contributions. 
Nominations of qualified individuals from 
both industrial and academic backgrounds 
are solicited. The successful candidate will be 


expected to provide leadership in both re¬ 
search and teaching. The academic rank 
will, of course, be Professor with tenure. 

Sophisticated and complex parallel soft¬ 
ware systems will be the driving forces for 
much of computer science and engineering 
during the next decade. Software system 
applications will range from scientific compu¬ 
tation, to business applications, engineering 
applications, to real-time embedded sys¬ 
tems. A broad range of problems must be 
addressed in these areas including software 
engineering research on software develop¬ 
ment methodologies, tools and environ¬ 
ments; parallel algorithms; scheduling for 
distributed and parallel real-time systems; 
languages for real-time and parallel systems; 
development of theoretic foundations for 
such systems, etc. The chair recipient will 
have a leadership role in this development at 
Texas A&M. 

Texas A&M is making a major commit¬ 
ment to establishing an outstanding program 
in Computer Science and Engineering. A 
substantial external contribution has enabled 
the creation of a heavily endowed chair in 
software engineering and parallel computa¬ 
tion systems area as part of this effort. The 
Department will move into a new building in 
January 1990. With the building the Depart¬ 
ment will receive an allocation of $1,500, 
000.00 for new equipment. In addition, the 
College is preparing to make substantial in¬ 
vestments in facilities to support leading edge 
research in areas involving advanced com¬ 
puter architectures. There is strong industry 
support for Department advances and am¬ 
ple opportunity for joint industry/university 
endeavors. The successful candidate can 
play a major role in the decisions to be made 
in these areas, and will have the opportunity 
to shape the direction of software engineer¬ 
ing and parallel computation systems re¬ 
search in the Department. 

Please send nominations to Professor 
Richard A. Volz, Head, Department of 
Computer Science, Texas A&M University, 
241 Zachry Engineering Center, College 
Station, Texas 77843. Initial screening will 
include applications received prior to April 1, 
1989. Minorities and women are particularly 
encouraged to apply. 


XAVIER UNIVERSITY 
OF LOUISIANA 

Tenure track position to begin in August 
1990. Qualifications: Ph.D. in Computer 
Science preferred or Masters degree in Com¬ 
puter Science required from an accredited 
institution. Expect to teach 3 to 4 under¬ 
graduate courses per semester. Xavier Uni¬ 
versity of Louisiana is a Catholic Liberal Arts 
University serving a predominantly Black 
student body. The Computer Science De¬ 
partment offers 2 programs leading to a B.S. 
in Computer Science or Computer Informa¬ 
tion Systems. Send resume or further in¬ 
quiries by April 30, 1990 to: 

Ms. Fatma Dandashi, Chairperson 
Computer Science Department 
P.O. Box 50A 
Xavier University 
New Orleans, LA 70125 
or call (504) 483-7458. 


March 1990 
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UNIVERSITY OF WASHINGTON 

Department of Computer Science 
and Engineering 

Department of Statistics 

The University of Washington seeks can¬ 
didates for a possible tenure track position in 
scientific/statistica! computing, to be held 
jointly in the Department of Computer Sci¬ 
ence and Engineering and in the Depart¬ 
ment of Statistics. Applicants should have a 
Ph.D. in Computer Science, Statistics, or a 
closely related field. We are specially in¬ 
terested in applicants with research interests 
in languages and systems for scientific com¬ 
puting, databases and information retrieval, 
or scientific visualization and graphics. 

The Department of Statistics is a leading 
center of research in statistical computing, 
meaning computing research relevant to the 


mary, and understanding of data used in 
decision making in science, engineering, 
public policy, and business. 

A moderate teaching load allows time for 
quality research and close involvement with 
students. We expect applicants to have a 
strong commitment to both research and 
teaching, and an outstanding record of 
research for their level. Any appointment 
should bring significant new research 
strength to both departments. Any applicant 
should be interested in collaborative research 
with faculty in both departments. 

Interested applicants should send a letter 
of application, a resume, and the names of 
four references to Computer Sciences/Sta- 
tistics joint Recruiting Committee, Depart¬ 
ment of Computer Science FR-35, Universi¬ 
ty of Washington, Seattle, Washington 
98195. 

AA/EOE 


UNIVERSITY OF HOUSTON 

Applications are invited for tenure track 
faculty positions in the Department of Com¬ 
puter Science starting September 1990. 
Areas of special interest include but not 
limited to artificial intelligence, computer ar¬ 
chitecture, computer graphics, computer 
networks, operating systems, programming 
languages and software engineering. Rank 
and salary are open and competitive. The 
Department is interested in expanding its 
research program and particularly welcome 
applicants for senior positions. Applicants 
should have a Ph.D. in Computer Science or 
a closely related area, and a strong commit¬ 
ment to research and teaching. Candidates 
for senior positions should also have a 
distinguished research record. The Depart¬ 
ment offers Ph.D., M.S., and B.S. in Com¬ 
puter Science. Departmental research facili¬ 
ties include a network of SUN Workstations, 
VAX 11/780 and VAX 11/730’s, a net¬ 
work of AT + T 3B20 and 3B2’s and access 
to other computing facilities in the University 
Computer Center as well as supercomputers 
via remote access terminals. Send resume 
and names of professional references to Dr. 
Willis King, Chairman, Department of Com¬ 
puter Science, University of Houston, 
Houston, Texas 77204-3475. An Equal Op¬ 
portunity/Affirmative Action Employer. 


VANDERBILT UNIVERSITY 
Department of Electrical Engineering 

Applications for research positions at the 
rank of Research Assistant Professor are so¬ 
licited from highly qualified individuals with a 
strong entrepreneurial spirit, and commit¬ 
ment to sponsored research and teaching. 
Candidates should have demonstrated 
abilities and interest in the following fields: ar¬ 
tificial intelligence, parallel processing and 
real-time systems. Applicants must have a 
Ph.D. in Electrical or Computer Engineer¬ 
ing. Please submit a detailed resume in¬ 
cluding a statement of professional interest 
to: Prof. George E. Cook, Chairman, 
Search Committee, Robotics and Automa¬ 
tion Research Group, Department of Elec¬ 
trical Engineering, Vanderbilt University, 
Box 1824, Station B, Nashville, TN 37235. 

EOAA Employer. 


THE UNIVERSITY OF TENNESSEE, 
KNOXVILLE 

Vice-Chancellor for Computing and 
Telecommunications 

Applications and nominations are invited 
for the position of Vice-Chancellor for Com¬ 
puting and Telecommunications. The Vice- 
Chancellor’s responsibilities will include: 
strategic planning for both academic and ad¬ 
ministrative computing; development and 
management of administrative information 
systems; development, maintenance and 
expansion of a campus-wide telecommuni¬ 
cations network; development of policies 
and procedures for coordination, planning, 
and resource sharing for academic comput¬ 
ing in various campus units; planning, in 
conjunction with the libraries, for the scholar¬ 
ly information environment of the campus. 

The successful candidate must have ex¬ 
perience in both academic and administra¬ 
tive computing, the ability to balance the 
needs of instruction, research and admini¬ 
stration in the allocation of resources, as well 
as the ability to promote and maintain effec¬ 
tive and innovative academic and admini¬ 
strative applications of telecommunications 
systems to meet the needs of students, facul¬ 
ty, and staff. An advanced degree is re¬ 
quired, a Ph.D. is preferred. A faculty ap¬ 
pointment would be available for a suitably 
qualified candidate. 

The successful candidate will have an 
understanding of and demonstrated com¬ 
mitment to equal employment opportunity 
and Affirmative Action. 

Salary will be commensurate with qualifi¬ 
cations and experience. Applications should 
include a recent resume and the names of at 
least three references. Review of applications 
will begin March 1 and will continue until the 
position is filled. 

Nominations and applications should be 

Dr. Joseph Trahern, Jr., Chair 
Vice-Chancellor Search Committee 
Office of the Chancellor 
527 Andy Holt Tower 
The University of Tennessee 
Knoxville, TN 37996-0150 
The University of Tennessee is an EEO/ 
Affirmative Action/Title IX, Section 504 
Employer. 


TRINITY COLLEGE 
Computer Science Faculty 

Trinity College is establishing a Depart¬ 
ment of Computer Science and is seeking 
candidates at any level for a tenure track 
position starting in August 1990. The success¬ 
ful candidate will join two other computer 
science faculty in the continued develop¬ 
ment of the computer science major which 
was begun in 1985 and is presently offered 
through the Department of Engineering and 
Computer Science. 

Candidates must have a Computer Sci¬ 
ence Ph.D., a strong commitment to excel¬ 
lence in undergraduate teaching, a willing¬ 
ness and ability to participate in the continued 
development of a strong liberal arts com¬ 
puter science major and the potential to pur¬ 
sue an active research program. Applicants 
in all areas of computer science will be 
considered. 

Trinity College is a selective liberal arts 
college with a strong commitment to the sci¬ 
ences. In addition to computer science, the 
College offers majors in engineering, mathe¬ 
matics, chemistry, biochemistry, physics, bi¬ 
ology and psychobiology. The College’s aca¬ 
demic computing facilities include a VAX 
8350, a network of Sun 3/50 and 3/60 
workstations and numerous personal com¬ 
puters. Trinity College is an equal opportuni¬ 
ty/affirmative action employer, and has a 
primary goal of increasing the number of 
women and minority faculty in the sciences. 
Please send application letter, vita and letters 
of reference to Professor Ralph Walde, 
Department of Engineering and Computer 
Science, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin immediately and the search will remain 
open until the position is filled. 


NORWICH UNIVERSITY 

Tenure Track position in the Department 
of Computer Science and Engineering start¬ 
ing July 1990. Rank and salary commensu¬ 
rate with experience. Ph.D. desired, but will 
consider Masters with significant experience. 
Recently unified Computer Science and 
Computer Engineering program. Resources 
include: VAX Cluster, MicroVax, AT&T 
3B2 400, VAX Stations and numerous PCs. 
New faculty member will be responsible for 
teaching courses in an undergraduate Com¬ 
puter Science curriculum and assisting in 
curriculum and laboratory development. Ex¬ 
pertise in any of the following areas desired: 
Computational Algorithms, Simulation, 
Operating Systems, Computer Graphics, 
Programming Languages, AI and Software 
Methodology. A strong commitment to 
undergraduate education is essential. Appli¬ 
cations will be accepted until the position is 
filled. Norwich University is located in an 
area of Central Vermont that offers small 
town or rural living with outstanding recrea¬ 
tional opportunities. Must be U.S. Citizen or 
Permanent Resident. Send resume and ref¬ 
erences to Dr. Michael C. Murphy, Head, 
Computer Science and Engineering Depart¬ 
ment, Norwich University, Northfield, Ver¬ 
mont 05663. EOE. Women and minorities 
encouraged to apply. 
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CALIFORNIA STATE UNIVERSITY 
San Bernardino 

Position for Assistant or Associate Pro¬ 
fessor (tenure track) of Computer Science. 
Salary range $35,284-154,516 depending 
on qualifications and experience. Moving 
expenses. Available January, April or Sep¬ 
tember 1990. 

Duties include teaching, advising, curricu¬ 
lum development, research, and community 
interaction. Interest in digital logic, hard¬ 
ware, networking, and/or data bases is 
especially desirable. Teaching load equated 
to 12 hrs/wk of lecture and lab. Ph.D. in 
CSci is required. Facilities include CDC 
Cyber, Prime, IBM 4381 and Intel Hyper¬ 
cube computers, 286 and 386 PCs, micro¬ 
processors, terminals and several LANs. 

The University is located in one of the 
fastest growing service areas in the USA with 
a current student population of about 11000 
including 270 computer science majors. The 
area is noted for its warm climate and is 
within a 1-2 hr drive of mountain ski resorts, 
ocean beaches, and metropolitan Los 
Angeles. Housing costs average 20% lower 
than the LA area. Applicants should submit 
letter of application and vitae. Women and 
minorities are encouraged to apply. Position 
open until filled, but no later than June 1, 
1990. Send materials to: Dr. Peter Wetter- 
lind, Chair, Department of Computer Sci¬ 
ence, California State University, 5500 
University Parkway, San Bernardino, CA 
92407, PAAAAAR@CALSTATE.BITNET 

An Equal Opportunity/Affirmative Ac¬ 
tion, Section 504, Title IX Employer. 


GEORGIA INSTITUTE OF 
TECHNOLOGY 
School of Information and 
Computer Science 

The School of Information and Computer 
Science, soon to be incorporated in a newly 
created College of Computing, invites appli¬ 
cations for faculty positions at all levels, al¬ 
though preference will be given to applicants 
with several years of experience since the 
completion of a Ph D. Aplicants should have 
a commitment to teaching and a record of 
outstanding research accomplishments. 

The School seeks applicants to strengthen 
its programs in all areas of computer science, 
although we have special interest in candi¬ 
dates in the areas of networking and tele¬ 
communications, software engineering, 
human-computer interaction, scientific com¬ 
puting and realtime computing. Very com¬ 
petitive salaries are offered. 

The School has 32 faculty members and 
anticipates further growth. Its educational ac¬ 
tivities include an undergraduate program 
accredited by the Computing Sciences Ac¬ 
creditation Board, Inc., a Masters program 
with 100 students, and a Ph.D. program 
with over 90 students. 

The School is in the third year of a five 
year Coordinated Experimental Research 
grant from the National Science Foundation. 
This grant is funding acquisition of hardware 
and design and development of software to 
support parallel and distributed computing. 
Current equipment includes a large number 
of SUN Unix workstations, a 32-node BBN 


Butterfly multiprocessor, a 10-node Sequent 
Symmetry multiprocessor, and other special¬ 
ized equipment. 

Georgia Tech is located in Atlanta, which 
has a mild sunbelt climate. Atlanta is the 
center of commerce in the Southeast, offer¬ 
ing a diverse economy, good cultural and 
recreational opportunities, extremely attrac¬ 
tive residential neighborhoods, and afford¬ 
able housing. 

Candidates should send complete resumes 
and names of at least three references to: 
Professor William Appelbe, Faculty Search 
Committee Chairman, School of Informa¬ 
tion and Computer Science, Georgia Insti¬ 
tute of Technology, Atlanta, GA 30332 
(404) 894-6187, internet mail address: bill@ 
gatech.edu. 


UNIVERSITY OF WEST FLORIDA 
Division of Computer Science 

Applicants are invited for two tenure track 
positions in the Division of Computer Sci¬ 
ence. The successful candidates must hold a 
Ph.D. in Computer Science or closely re¬ 
lated field, and have a depth of knowledge in 
one or more of the following areas: construc¬ 
tivist approaches to AI and cognitive science, 
expert systems, knowledge acquisition, neu¬ 
ral nets, and image processing. 

The Division of Computer Science is an 
independent academic unit reporting to the 
Vice President of Academic Affairs. It offers 
a B.S. and M.S. degree in computer science 
and over the next few years will continue the 
development of its research and graduate 
programs including doctoral level work. Ex¬ 
tensive opportunities exist for local research 
involvement with the military and the 
medical communities. The Division currently 
enrolls about 650 undergraduate and 200 
graduate students. In addition, the Division 
houses the Institute for the Interdisciplinary 
Study of Human and Machine Cognition. 
The research environment includes a 
Solbourne Series 4, Sun SPARCstations, 
Lisp machines, IBM mainframe, and 
numerous Macintosh computers. 

Competitive salaries combined with a very 
low cost of living enhance the excellent life¬ 
style available in northwest Florida. 

Vitae and letter of application should be 
sent to Dr. Theodore Elbert, Division Head, 
Computer Science, The University of West 
Florida, Pensacola, FL 32514. The positions 
will remain open until filled. UWF is an 
EO/AA institution. 


UNIVERSITY OF HOUSTON 
Electrical Engineering 

Applicants are invited to apply for several 
tenure-track positions. Areas of interest are 
applied electromagnetics, biomedical engi¬ 
neering, communications, computer engi¬ 
neering, electronics, microelectronic pro¬ 
cessing and materials, image and signal 
processing, and robotics. Openings are 
available at all ranks. Please send resume to 
Dr. Stuart Long, Chairman, Department of 
Electrical Engineering, University of 
Houston, Houston, TX 77204-4793. 
Phone: (713) 749-2511. An Equal Oppor¬ 
tunity Employer. 


CLARKSON UNIVERSITY 
Electrical and Computer 
Engineering Department 

Applications are invited for tenure-track 
faculty positions at the Assistant/Associate/ 
Full Professor level. Openings exist in the 
computer engineering area as well as in solid 
state, power systems, and communications 
systems. A doctorate is required. Review of 
applications will begin February 28, and will 
continue until the positions are filled. Re¬ 
sponsibilities include undergraduate and 
graduate teaching and development of a 
research program. 

The department offers programs at the 
B.S., M.S., and Ph.D. levels. Last year 215 
bachelors, 11 masters, and 10 doctorates 
were awarded, and research funding reached 
the level of $1.3 million dollars. Principle 
research areas include distributed and 
parallel computation, artificial intelligence, 
image and signal processing, robotics and 
control, power engineering, solid state 
devices, electromagnetic scattering, and 
communication theory. There are research 
laboratories in AI and neural computing, 
VLSI design, lasers and optics, solid state 
device fabrication, high voltage engineering, 
and dielectric breakdown. There are ex¬ 
cellent computer facilities throughout the 
university, and Clarkson was the first univer¬ 
sity to require all of its freshmen to have a 
personal computer. 

Clarkson is an independent college spe¬ 
cializing in engineering, science and man¬ 
agement with an undergraduate enrollment 
of 3200 students and a graduate enrollment 
of 400 students. Located in Northern New 
York, Clarkson is midway between the St. 
Lawrence River and the Adirondack Moun¬ 
tains and a two hour drive from both Ottawa 
and Montreal. Send applications to Profes¬ 
sor Henry Domingos, Acting Chairman, 
Department of Electrical and Computer 
Engineering, Clarkson University, Potsdam, 
NY 13699. Clarkson is an Equal Opportun¬ 
ity/Affirmative Action Employer. 


CHAPMAN COLLEGE 

Computer Science Program Coordinator. 
Administrative position with some teaching 
responsibilities. Full time ten month appoint¬ 
ment. Assistant/Associate rank. Salary com¬ 
mensurate with qualifications and exper¬ 
ience. Summer/Fall, 1990, appointment. 
Responsible for academic coordination of 
undergraduate and graduate programs in 
computer science and computer information 
systems at multiple sites in Western United 
States; travel required. Teach computer 
science courses. Master’s degree in com¬ 
puter science required (doctorate preferred) 
and secondary preparation in information 
systems highly desirable. Demonstrated ex¬ 
cellence in administration and teaching and 
interest in program marketing and develop¬ 
ment required. Send resume, three letters of 
reference, and evidence of administrative 
and teaching experience to Gary Ramet, 
Chair, Department of Computer Science, 
Chapman College, Orange, CA 92666. 
Deadline: April 16, 1990. An Affirmative 
Action/Equal Opportunity Employer. 
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Designing the Future of 
Software Engineering Education 
Software Engineering Institute 
Carnegie Mellon University 

The SEI Software Engineering Curricu¬ 
lum Project provides a unique opportunity 
for educators to work in an environment 
where high-quality education is the first and 
only priority. The project is designing under¬ 
graduate and graduate software engineering 
curricula for the 1990s and beyond, creating 
educational support materials, and promot¬ 
ing the growth of software engineering edu¬ 
cation through conferences and workshops. 

We are seeking an innovative educator to 
join our technical staff. Qualifications include 
at least three years of college or university 
teaching experience in computer science, 
superior oral and written communication 
skills, and a strong commitment to software 
engineering education. 

The Software Engineering Institute is dedi¬ 
cated to the rapid advancement of the state 
of the art and practice of software engineer¬ 
ing. The Institute is part of Carnegie Mellon 
University, one of the world’s most stimulat¬ 
ing intellectual environments for computing 
professionals. The SEI technical staff enjoy 
outstanding computing resources, substan¬ 
tial administrative, research, and document 
production support, and competitive salaries. 

To apply, please send a resume or curricu¬ 
lum vitae to Sally Miller, Software Engineer¬ 
ing Institute, Carnegie Mellon University, 
Pittsburgh, Pennsylvania 15213. 

Carnegie Mellon University is an equal op¬ 
portunity/affirmative action employer. The 
Software Engineering Institute is sponsored 
by the Department of Defense. U.S. citizen¬ 
ship or resident alien status required. 


LAMAR UNIVERSITY 
Computer Science 
Department Faculty Positions 

The Computer Science Department at 
Lamar University has two tenure-track 
Assistant/Associate Professor positions 
available beginning in the Spring 1990 
semester. 

Our program has 350 undergraduate 
C.S. majors, and 55 graduates. There are, 
at present, eight full-time and five part-time 
faculty members in the department, with in¬ 
terests ranging from Artificial Intelligence to 
Operating Systems. 

Lamar is currently installing a clustered 
VAX network, while carefully considering 
the possible directions Computer Science 
might take during the next five years. We 
think our relatively young program offers an 
excellent opportunity for a young graduate. 

For individuals who are outdoor oriented, 
Beaumont is an ideal location. It is within 30 
minutes of salt/fresh water fishing, sailing, 
the Big Thicket National Forrest Reserve, 
Sea Rim State Park, and 3 public golf 
courses. Both Houston and Galveston are 
within 1V2 hours from the greater Beaumont 
area. Beaumont has a fine symphony or¬ 
chestra. Housing costs are relatively low and 
the region is conducive to family living. 

Lamar is a middle-state university with a 
student population of 15,000. The Com¬ 
puter Science Department is housed within 


the College of Engineering. Degrees offered 
by the department include a B.S. in Com¬ 
puter Science, a B.S. in Computer and In¬ 
formation Systems, a B.S. with a double 
major in Electrical Engineering Computer 
Science, and an M.S. in Computer Science. 

Applicants should respond to Dr. Ronald 
King, Computer Science Department, 
Lamar University, P.O. Box 10056, Beau¬ 
mont, TX 77710, (409) 880-8775. 


NAVAL POSTGRADUATE SCHOOL 

The Computer Science Department invites 
applications for faculty positions at all levels. 
Our primary interests are in the areas of 
operating systems and programming lan¬ 
guages. Our secondary interests are in the 
areas of visual data processing, graphics, 
and computer architecture (especially real¬ 
time and parallel-processing aspects of the 
three). Applicants should have a Ph.D. in 
Computer Science or a closely related field 
and be committed to high-quality teaching 
and research. Senior applicants must have 
distinguished research records. Appoint¬ 
ments can begin at any time. 

The Department offers M.S. and Ph.D. 
degrees in computer science, but no under¬ 
graduate degrees. Currently, 110 students 
are enrolled in the M.S. program and five in 
the Ph.D. program. Students are military of¬ 
ficers or civilian employees of the Depart¬ 
ment of Defense and are fully supported by 
their sponsoring organization during their 
studies. Departmental facilities (supported 
by eight full-time computer professionals) in¬ 
clude six instructional and research labora¬ 
tories with extensive state-of-the-art equip¬ 
ment. Faculty normally teach for two quarters 
and perform research for two quarters per 
year. The Monterey-Carmel area provides a 
pleasant coastal climate and easy access to 
Silicon Valley companies. 

Send a detailed resume, an abstract of 
your best recent research, and letters of ref- 

Faculty Search Committee 
Computer Science Department, Code 52 
Naval Postgraduate School 
Monterey, CA 93943 
Telephone (408) 646-2449 
An Equal Opportunity/Affirmative Action 
Employer 


RENSSELAER POLYTECHNIC 
INSTITUTE 
Faculty Positions 

Department of Electrical, Computer 
and Systems Engineering 

Rensselaer Polytechnic Institute, Depart¬ 
ment of Electrical, Computer, and Systems 
Engineering, invites applications for tenure- 
track faculty positions at all levels. Specific 
areas of interest include: (1) computer engi¬ 
neering, architecture, and performance 
evaluation; (2) computer and communica¬ 
tions networks, architectures and protocols. 
Senior faculty applicants with an interest in 
undertaking a leadership role in these re¬ 
search programs are encouraged. The ECSE 
Department is the largest academic unit at 
Rensselaer and has a rich tradition of re¬ 
search and education. The department is 


seeking to add faculty who bring an innova¬ 
tive approach to research and teaching. 
Active programs in computer engineering, 
solid-state electronics and integrated circuit 
design, control systems, robotics and 
automation, information and decision sys¬ 
tems, communications and signal process¬ 
ing, electronics and circuits, and fusion 
plasma systems contribute to a dynamic re¬ 
search environment. In addition to the ex¬ 
tensive research facilities of the department, 
there are opportunities to initiate or par¬ 
ticipate in interdisciplinary research pro¬ 
grams in one of the major research centers of 
the School of Engineering, including the 
Center for Integrated Electronics, the Rens¬ 
selaer Design Research Center, the Center 
for Manufacturing Productivity and Technol¬ 
ogy Transfer, and the NASA Center for In¬ 
telligent Robotic Systems in Space Explora¬ 
tion. New faculty are eligible for special ar¬ 
rangements including summer support, 
equipment, graduate student support, and 
reduced teaching load in order to encourage 
growth of their research programs. Applica¬ 
tions or requests for more information 
should be directed to: 

Dr. Arthur C. Sanderson, Chairman 
Electrical, Computer, and Systems 
Engineering Department 
Rensselaer Polytechnic Institute 
Troy, NY 12180-3590 
RPI is an affirmative action/equal oppor¬ 
tunity employer. 


Designing the Future of 
Software Engineering Education 
Software Engineering Institute 
Carnegie Mellon University 

The SEI Software Engineering Curricu¬ 
lum Project provides a unique opportunity 
for educators to work in an environment 
where high-quality education is the first and 
only priority. The project is designing under¬ 
graduate and graduate software engineering 
curricula for the 1990s and beyond, creating 
educational support materials, and promot¬ 
ing the growth of software engineering edu¬ 
cation through conferences and workshops. 

We are seeking an innovative educator to 
join our technical staff. Qualifications include 
at least three years of college or university 
teaching experience in computer science, 
superior oral and written communication 
skills, and a strong commitment to software 
engineering education. 

The Software Engineering Institute is dedi¬ 
cated to the rapid advancement of the state 
of the art and practice of software engineer¬ 
ing. The Institute is part of Carnegie Mellon 
University, one of the world’s most stimulat¬ 
ing intellectual environments for computing 
professionals. The SEI technical staff enjoy 
outstanding computing resources, substan¬ 
tial administrative, research, and document 
production support, and competitive salaries. 

To apply, please send a resume or curricu¬ 
lum vitae to Sally Miller, Software Engineer¬ 
ing Institute, Carnegie Mellon University, 
Pittsburgh, Pennsylvania 15213. 

Carnegie Mellon University is an equal 
opportunity-affirmative action employer. 
The Software Engineering Institute is spon¬ 
sored by the Department of Defense. U.S. 
citizenship or resident alien status required. 
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UNIVERSITY OF NOTRE DAME 
Chairperson 

Department of Computer Science 
and Engineering 

The University of Notre Dame invites ap¬ 
plications for the Chair of the newly-estab¬ 
lished Department of Computer Science and 
Engineering in the College of Engineering. 
This position is a unique opportunity to pro¬ 
vide significant input in establishing direction 
for the initiation and growth of programs in 
this department. Persons with established 
records in education and scholarship who 
would welcome the challenge of developing 
a department and its programs are encour¬ 
aged to apply. The faculty of the department 
will be expected to determine the curriculum 
leading to graduate and undergraduate 
degrees in computer science and computer 
engineering. 

It is anticipated that the Department of 
Computer Science and Engineering will in¬ 
itially have twelve tenure-track faculty posi¬ 
tions, with four of these faculty transferred 
from the present Department of Electrical 
and Computer Engineering. The Depart¬ 
ment of Electrical and Computer Engineer¬ 
ing will become the Department of of Elec¬ 
trical Engineering, and its present graduate 
and undergraduate programs in computer 
engineering are expected to provide the 
foundation for the new department. It is an¬ 
ticipated that the Department of Computer 
Science and Engineering will have close co¬ 
operative ties with the Department of Elec¬ 
trical Engineering, Department of Mathema¬ 
tics, and other academic units. 

Qualified applicants are encouraged to 
submit a resume and letter of interest to: 

Dr. Panos J. Antsaklis 

Department of Electrical and Computer 
Engineering 

University of Notre Dame 

Notre Dame, IN 46556 

For additional information, please contact 
the Dean’s office at (219) 239-5534. 

The University of Notre Dame invites ap¬ 
plications from all qualified persons without 
regard to sex, ethnic origin, religious prefer¬ 
ence or physical impairment. 


INDIANA UNIVERSITY NORTHWEST 
Computer Science/Data Processing 
and Information Systems 

One or two tenure track positions avail¬ 
able beginning in August 1990 in the Depart¬ 
ment of Data Processing and Information 
Systems (DPIS). A Ph D. degree in Com¬ 
puter Science/Information Systems or a 
Ph.D. in a related area with a master’s 
degree in Computer Science/Information 
Systems strongly preferred. Competence in 
one or more of the following areas desirable: 
applied programming techniques; program¬ 
ming languages such as FORTRAN, PAS¬ 
CAL, SCHEME etc; expert systems; artificial 
intelligence; database management systems; 
data processing management; information 
systems design and development; or com¬ 
puter simulation and modeling. One who 
could serve as departmental chairman is 
especially sought. Indiana University North¬ 
west, located in Gary, Indiana, is one of tne 
eight campuses of the Indiana University 


system. The DPIS department offers pro¬ 
grams leading to associate and baccalaureate 
degrees and post-baccalaureate certificates. 
Tenure track faculty receive a teaching 
course load reduction and are expected to 
establish and maintain a productive research 
program. Salary and rank are dependent on 
training and experience. Application dead¬ 
line is March 19, 1990. Send letter of ap¬ 
plication, transcripts, curriculum vitae and 
the names, addresses and telephone num¬ 
bers of three references to: 

Dr. Lynne Merritt, Jr., Acting Chairman 
Department of Data Processing & 
Information Systems 
Indiana University Northwest 
3400 Broadway 
Gary, Indiana 46408 
An Affirmative Action/Equal Opportunity 
Employer. 


SYSTEM ANALYST/ 
SCIENTIFIC PROGRAMMER 

State geological survey at major mid-west 
university needs a System Analyst/Scientific 
Programmer. Require M.S. Degree in Elec¬ 
trical Engineering or Computer Science. 
Also require skills in geometric modeling, 3D 
graphics and surface shading, and use of 
Petroleum Information Corporation Well 
History Control System. Must be skilled in 
the use of SURFACE III software for map¬ 
ping and in programming with FORTRAN 
77, PASCAL, and C languages. Must be 
knowledgeable in development of computer 
software systems for simulation of sedimen¬ 
tary processes. Position will support Pet¬ 
roleum Research Section and Automated 
Cartography group within Technical Infor¬ 
mation Services Section. Responsible for 
development and management of front-end 
programs for interactive graphics and data 
retrieval on Data General MV/20000 com¬ 
puter with usertransparent shifts between 
software packages. Also develop custom 
programs to build and manage large data¬ 
bases and analyze data for research section 
projects. Develop forward and inverse com¬ 
puter simulations of dynamic geologic sys¬ 
tems. Assist in data management and geo¬ 
logic interpretations related to simulation 
models. Salary, $28,000.00/year, 40 hours/ 
week. Please submit resume to Lawrence 
Employment & Training Office, 833 Ohio 
Street, Lawrence, Kansas 66046. RE: Job * 
KS1900492. 


CONCORDIA COLLEGE 
Computer Science 

Assistant professor or instructor tenure- 
track faculty positon. Ph D. in Computer 
Science preferred, ABD considered. Must be 
in sympathy with the aims of a liberal arts col¬ 
lege of the Evangelical Lutheran Church in 
America. Teach upper-division undergrad¬ 
uate courses in Database and lower-division 
courses in Computer Science as assigned; 
student advisement and college committee 
service. Send letter of application, creden¬ 
tials, and references by March 15, 1990 to: 
Dr. Orvald Haugsby, Chair, Department of 
Mathematics and Computer Science, Con¬ 
cordia College, Moorhead, MN 56562. An 
Equal Opportunity Employer. 


CASE INSTITUTE OF TECHNOLOGY 
NORD Professorship in 
Computer Engineering and Science 

The Department of Computer Engineering 
and Science at Case Institute of Technology 
is seeking a nationally recognized scholar 
and researcher to fill the NORD Professor¬ 
ship. This position was recently established 
by the donation of one and a half million dol¬ 
lars, which will provide outstanding profes¬ 
sional opportunities and a highly competitive 
salary, together with additional funds for 
travel, graduate student support and equip¬ 
ment. The qualifications Include a Ph.D. in 
computer science, computer engineering or 
closely allied fields, and an ability to establish 
and develop external support for a nationally 
recognized research program in computer 
science/computer engineering. We invite 
applications from senior faculty at both the 
associate professor and full professor levels. 

CWRU is a private university with a total 
enrollment of 8,400, of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the huh of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has 15 faculty positions, and 
a graduate student body of 140 students, 50 
of which are in the Ph D. program. Depart¬ 
mental facilities are based upon an ethernet 
local area network, connected to INTER¬ 
NET, which supports a UNIX operating sys¬ 
tem and about 30 SUN workstations, color 
graphics display terminals, together with 
several printers. In addition, faculty and stu¬ 
dents participating in the Center for Automa¬ 
tion and Intelligent Systems Research have 
access to the Center’s computing facilities. 

Applicants should submit their curriculum 
vitae and names of at least five references to: 
Lee J. White, Chairman, Department of 
Computer Engineering and Science. 
Case Western Reserve University, Cleve¬ 
land, Ohio 44106; INTERNET: leew@alpha. 
ces.cwru.edu; applicants may wish to pro¬ 
vide at most three reprints of their most im¬ 
portant publications. 

An equal employment and affirmative ac¬ 
tion employer. 


NATIONAL CHIAO TUNG 
UNIVERSITY 

The Department of Computer & Informa¬ 
tion Science invites applications for Distin¬ 
guished Professors and faculty positions in 
August 1990. The Department offers B.S., 
M.S. and Ph.D. degrees. A candidate must 
have a Ph.D. in computer science, engineer¬ 
ing, or related field. 

Please send resume and names of three 
references to; Professor Kou-Yuan Huang, 
Chairman, Department of Computer & In¬ 
formation Science, National Chiao Tung 
University, Hsinchu, Taiwan, R. O. C., 
Consideration of applications will begin in 
April 1990 and the search will remain open 
until the positions are filled. 
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IEEE COMPUTER SOCIETY 
Membership / Subscription Application 



BENEFITS 



Computer 

Computer comes automatically 
with membership. Written, 
reviewed, and refereed by 
experts, it features survey and 
tutorial articles covering the 
entire computer field, and 
departments such as new 
products, new product reviews, 
standards, and a reader forum 
called "The Open Channel.” 
(monthly). 


Technical Committees 

Participate in one or more of our 33 technical 
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BOOK REVIEWS 


Editor: Guy Johnson, Department of Information Technology, Rochester Institute of Technology, 1 Lomb Memorial Drive, Rochester, NY 14623 


Systems Design in a Database Environment 

Kenneth S. Brathwaite (McGraw-Hill, New York, 1989, 308 pp., $44.95) 


A better title for this book would be A 
Geography of System Design Tools and 
Techniques: A Survey. Brathwaite 
achieves his limited objective “to pro¬ 
vide readers with definitive information 
on topics that are crucial to the under¬ 
standing of what is required to develop a 
system from its conceptual stage through 
analysis, design, testing, implementa¬ 
tion, and performance monitoring.” But 
this quote also illustrates why the infor¬ 
mation provided isn’t enough to recom¬ 
mend this book. Brathwaite’s writing 
style overuses the passive voice, weak 
adverbs, and the word “that.” It is easy to 
slip into this style in conversation, but 
reading it really puts me off. 

The book covers a lot of ground; Brath¬ 
waite gives most of his attention to entity- 
relation diagrams as data-modeling tools 
and to CASE tools for system design. Be¬ 
cause of its broad survey approach, the 
book lacks a cohesive punch and couldn’t 
sustain serious use in a development proj¬ 
ect. I came away with the feeling that 
Brathwaite had covered all the issues 
without tying the loose ends. 

In the preface, Brathwaite states the 
book could be used in an introductory 
course in a business or technical school. 
Maybe in a business school, where the au¬ 
thor’s conversational style is more palat¬ 
able, but not in a technical school. He also 
states in the preface his expectation that 
most readers will skip his mathematically 
rigorous discussion of the database nor¬ 
malization process. In practice, though, 
database normalization is important to 
the performance trade-off that system de¬ 
signers must make between size and 
speed. While Brathwaite claims mathe¬ 
matical rigor, he has softened his treat¬ 
ment of normalization, and he misses an 
opportunity to give his book more pur¬ 
pose than a discourse. Without more fun¬ 
damental explanation, his examples lack 
the necessary rigor, clarity, and useful¬ 
ness. Better examples of normalization 
are found in Shaku Atre’s Database 
Structured Techniques for Design, Per¬ 
formance, and Management (John 
Wiley, second edition, 1988). 

Brathwaite describes the differences 
between the hierarchical, network, and 


relational database models. My own pref¬ 
erence is for the relational model, while 
Brathwaite admits his preference for 
IMS, a hierarchical database. He is proba¬ 
bly safe in claiming that the relational 
model is easier to build on, while the net¬ 
work and hierarchical models give better 
performance in their current implemen¬ 
tations. 

Brathwaite provides a smattering of 
maps to the territories he surveys, includ¬ 
ing examples of a logical schema, struc¬ 
ture charts, dataflow diagrams, coding 
sheets, and on-line terminal screens. The 
logical schema on page 61 suffers from an 
incomplete key, misplaced links between 
elements, and missing arrows on con¬ 
necting links. The few structure charts 
and dataflow diagrams are introduced as 
examples of CASE tools. Appendixes 
with pages of blank coding sheets are an¬ 
other clue to a soft exposition. Many on¬ 
line screens, heavy with repeated equal 
signs and asterisks, don’t provide any 
useful information, either. 

The book might be useful to managers, 
possibly with no prior software experi¬ 
ence, who find themselves in charge of a 
database project for the first time. Still, a 
better introduction would be John 
Grant’s Logical Introduction to Data¬ 
bases (Harcourt Brace Jovanovich, 

1987). 

A limited plus for Brathwaite’s book is 
the list of 50 CASE-tool vendors. The list 
seems complete, but it would be more 
helpful if the vendors’ addresses were 
provided. Eight of the vendors responded 
to a questionnaire on CASE-tool selec¬ 
tion criteria for a hospital insurance plan; 
Brathwaite provides the responses in an 
appendix. If I were selecting a CASE tool, 
one of my criteria would be the lucidity of 
these responses. 

Another book to consider that covers 
most of the same topics is Penny A. 
Kendall’s Introduction to Systems Analy¬ 
sis and Design: A Structured Approach 
(Allyn and Bacon, 1987). There are just 
too many good books out there to recom¬ 
mend Brathwaite’s. 

Marty McGowan 

AT&T Bell Labs 


Online 

Communications 

Software 

Ruth Ashley, Judi N. Fernandez, and 

Paul Ashley (McGraw-Hill, New 

York, 1989, 256 pp., $27.95) 

This book provides no biographical in¬ 
formation on the authors, but I suspect 
they are either frustrated bulletin board 
users who decided to educate others 
about bulletin board etiquette or com¬ 
puter lab staffers exhausted by recurring 
questions about communications soft¬ 
ware. Both areas are covered in this book. 

In addition to providing a brief but 
comprehensive overview of telecommu¬ 
nications with a personal computer, this 
book examines six popular communica¬ 
tions software packages in detail. The 
packages represent both retail (Crosstalk 
XVI, Smartcom II and III) and “share¬ 
ware” (PC-Talk III, Procomm, and 
Qmodem SST) products for IBM and 
IBM-compatible systems. 

The telecommunications overview pro¬ 
vides pertinent facts but does not dwell on 
technical specifics. These chapters ex¬ 
amine problems encountered by telecom¬ 
munications users who have call-waiting 
service and provide a technique to tempo¬ 
rarily disable the service. The authors 
also review modems and give advice for 
readers who are ready to purchase one. 

Although the text is almost simplistic 
at times, the authors manage to review all 
the details of communications. For ex¬ 
ample, the modem section includes a dis¬ 
cussion of the power supply required. 
Anyone who has ever helped a novice in¬ 
stall and use a modem knows that such 
information is vital. The term “Hayes- 
compatible” is explained as it pertains to 
personal-computer communication, an 
important detail not always included in 
the literature. The authors also discuss 
the advantages of software registration 
and the merits of data compression and 
archiving as they influence connect time 
to bulletin boards. 

Readers will get the most from this book 
if they buy it before selecting a modem 
and communications software. The book 
takes the reader through selection, set¬ 
up, and use in both personal and business 
settings. The authors write in a conversa- 
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tional style, almost as though the reader 
were conducting a moderately technical 
dialogue with a well-informed friend. 

The authors’ discussion of a first con¬ 
nection to a bulletin board system is a 
brief treatment of what could be a rather 
involved experience for the uninitiated. 
Unfortunately, this discussion also pre¬ 
cedes the chapters that discuss the specific 
communications products, so a true nov¬ 
ice will have a difficult time following the 
example. The discussion also would have 
been helped by showing example screens 
from a representative system. 

The authors do not directly compare or 
rank the programs’ features. Rather, each 


chapter sticks strictly to one product, giv¬ 
ing the reader the maximum information 
for making an informed decision. The au¬ 
thors also provide an index that lists pri¬ 
mary keywords under the specific prod¬ 
uct listings. 

All the products except PC-Talk III are 
covered in two chapters, with the first de¬ 
signed to get the user on line quickly and 
the second devoted to additional product 
features. The authors use screen displays 
and examples of scripts and command 
files throughout these chapters. In fact, 
working with this book was easier for me 
than working with the Procomm and 
Smartcom II documentation. The au¬ 


thors’ strategy of getting as much infor¬ 
mation to the user as quickly as possible 
helped me find out about product features 
I had never reached in the documentation. 

This book is a solid addition to a per¬ 
sonal-computer library. It would be a use¬ 
ful reference whether you are consider¬ 
ing a communications software package 
or have already selected one of the pack¬ 
ages covered. It would also provide 
needed instruction to students who must 
learn communications without the bene¬ 
fit of a class or lab. 

Patricia A. Morreale 

Illinois Institute of Technology 


A Program Architecture for Improved Maintainability in 
Software Engineering 

John Einbu (John Wiley & Sons, New York, 1989, 167 pp„ $39.95) 


Glenford Myers once said his favorite 
definition of structured programming 
was “the attitude of writing code with the 
intent of communicating with people in¬ 
stead of machines” (Software Reliabil¬ 
ity: Principles and Practices, John 
Wiley, 1976). A few years later, James 
Martin and Carma McClure called under- 
standability “perhaps the most funda¬ 
mental requirement for a maintainable 
program” (Software Maintenance: The 
Problem and Its Solutions, Prentice Hall, 
1983). John Einbu states that “the most 
crucial problem of software engineer¬ 
ing” is “how to make programs under¬ 
standable,” so it is no surprise that he cites 
Martin and McClure several times. How¬ 
ever, his failure to cite Myers even once is 
a clear sign of his book’s unevenness. 

The central problem with the book is 
that most of the points have been made 
many times before, and the most impor¬ 
tant point is not made at all. I wholeheart¬ 
edly agree with Einbu’s main thesis that 
“it is more beneficial to make a program 
understandable than to give it a structure 
that makes the control flow visible.” I 
also agree that structured programming 
has not solved the software crisis. Every 
programming environment should adopt 
many of the attitudes and techniques 
Einbu discusses, particularly his funda¬ 
mental assumption that “the best overall 
results in program development are 
achieved if as much attention is paid to 
the maintenance programmer’s require¬ 
ments as to the user’s requirements.” But 
this is just what Myers, Martin, McClure, 
and others have been saying for years. 

The thrust of Einbu’s argument is that 
program architecture produces program 


understandability. In Chapter 5, he de¬ 
fines at length the following as compo¬ 
nents of program architecture: calling 
hierarchy, program length, indentation, 
decomposition, comments, declarations, 
common blocks, statements, primitive 
program elements, subprogram and vari¬ 
able identifiers, and labels. Even though 
he considers his audience to be working 
programmers as well as students, it is not 
clear that his choice of Fortran — and his 
lengthy discussion of Fortran-specific 
program elements — will be “welcomed 
by the majority of readers,” as he main¬ 
tains. Be that as it may, many of Einbu’s 
central concepts are almost as hoary as 
Fortran (perfective maintenance, for ex¬ 
ample, was defined at least as early as 
1976). 

All of which begs the question: Why 
haven’t these concepts been adopted? 
Why aren’t we already doing what Einbu 
argues we should be doing? Why haven’t 
we solved the software maintenance cri¬ 
sis? The answer does not lie in Fortran or 


structured programming or its lack. It lies 
in getting software engineers to use “pro¬ 
gram architecture” and in changing the 
pervasive attitude in schools and busi¬ 
nesses that maintenance programming is 
second-class work that is neither as satis¬ 
fying nor as rewarding as design and de¬ 
velopment. Until that change happens, 
none of the techniques and methods pro¬ 
posed by Einbu — or Myers or Martin and 
McClure — will make much difference or 
be much used. This is the point Einbu fails 
to make. 

The book ends with a splendid example 
of its overall unevenness: three appen¬ 
dixes (a programming standard, the For¬ 
tran source code for a program to print 
Fortran programs, and a Fortran program 
template), four pages of references, and a 
one-page index that contains entries for 
neither “understandability” nor “archi¬ 
tecture.” 

Robert C. Birss 

Sun Microsystems 


Reviewers wanted 

If you are interested in reviewing books for Computer, please submit your 
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Principles of Computer-Aided Design: Modeling Objects 
and Environments 

Yehuda E. Kalay (John Wiley & Sons, New York, J989, $69.95) 


This study of nonspecific CAD pro¬ 
gramming and techniques for visualizing 
computerized data is the second of five 
books by Kalay dealing with computer- 
aided design. By presenting a brief over¬ 
view of the origination and practical use 
of CAD software, Kalay offers a general 
understanding of the needs and shortcom¬ 
ings of past, present, and future software. 

Kalay uses illustrations and Pascal 
programs throughout the book to explain 
the concepts of modeling presentation. 
Starting with a single source point, he 
demonstrates how to generate, manipu¬ 
late, and modify two- and three-dimen¬ 
sional polygon-based objects by defining 
the requirements of each procedure and 
expanding them into computer programs. 
A variety of exercises encourage the 
reader to actually generate examples of 
CAD software. 

In Part 1, Kalay defines “well-formed¬ 
ness” with operators to create, modify, 
and delete polygons. Using various pro¬ 
gramming schema, he clearly defines each 
area of generation and manipulation using 
end points as identifiable locators within 
a computational frame of reference. 


Part 2 expands the information on two- 
dimensional polygons into a three- 
dimensional concept of space, including 
the generation and manipulation of sol¬ 
ids. Then, in Part 3, Kalay defines the 
principles of transforming those shapes 
into geometrically associated informa¬ 
tion about the shapes in two- and three- 
dimensional space. He discusses how 
associating the structures with known ob¬ 
jects, such as floor plans, can interrelate 
components by geography and hierarchy. 
Kalay also reviews relational and hierar¬ 
chical database structures, comparing 
their function with that of a user review¬ 
ing the graphic representations. The 
functional placement and manipulation 
elements and associated data are critical 
to these structures. 

Part 4 concentrates on how to represent 
and manipulate properties associated 
with objects that are not represented gra¬ 
phically. The appendixes explore in 
greater depth the areas discussed in the 
body of the book, including such ad¬ 
vanced procedures as menu generation 
and run-length encoding. Most of the 
chapters have a bibliography at the end. 


giving readers the opportunity to explore 
concepts further. 

The book is designed for readers with 
prior exposure to CAD and knowledge of 
Pascal. Having worked on four different 
CAD systems, I know that every CAD 
program has its own unique characteris¬ 
tics. 1 was therefore disappointed by 
Kalay’s attempt to offer a general under¬ 
standing of CAD software design based 
on “ideal” CAD software. Using a single 
programming format to explain CAD 
software design seems an insurmount¬ 
able task, akin to explaining a variety of 
programming languages without men¬ 
tioning any particular language. 

Overall, however, this book has its 
good points. Students learning to develop 
higher-level programs could find it help¬ 
ful. However, architects and engineers 
might find that the book’s overly broad 
approach does not give them the knowl¬ 
edge to select and operate the CAD sys¬ 
tems most suited to their individual needs. 


Maureen Alley 
E. Madison Consulting 


VLSI Handbook: Silicon, Gallium Arsenide, and 
Superconductor Circuits 

Joseph Di Giacomo, ed. (McGraw-Hill, New York, 1989, 720 pp„ $59.50) 


This book is a reference for anyone in¬ 
volved in developing VLSI circuits, in¬ 
cluding design engineers, CAD opera¬ 
tors, and management. The editor’s goal 
is to offer a clear understanding of the 
relationship among design, CAD, and 
factory interfaces by describing the de¬ 
velopment process from the customer’s 
perspective. 

The editor has brought together more 
than 30 VLSI specialists in 11 sections 
covering design, testing, fabrication, 
technology selection, design methodol¬ 
ogy, CAD tools, packaging, costs/pricing, 
reliability/yield analysis, analog circuits, 
and special topics such as gallium 
arsenide and superconductor circuits. 

Given the stated goal of describing the 
process from the customer’s perspective, 
1 was immediately disappointed with the 
book’s organization. As a customer, my 
own first concern is the economics of a 


given VLSI solution, but that topic is not 
discussed until Part 8. In today’s com¬ 
petitive environment, any product devel¬ 
oper should keep foremost in mind the 
need to provide products in a timely fash¬ 
ion that meet the customers’ cost, relia¬ 
bility, and performance objectives. 

Part 8 does cover most of the economic 
issues quite well. Authors Curt Fey and 
Demetris Paraskevopoulos include a 
thorough discussion of the relative eco¬ 
nomics of standard small- to medium- 
scale integration, programmable logic 
devices, gate arrays, standard cells, stan¬ 
dard large- to very large scale integra¬ 
tion, and full custom VLSI. The section 
offers ample evidence that, relative to the 
other technologies, gate arrays will find 
wider use in medium- to high-volume 
systems in the 1990s. However, the au¬ 
thors play down the risks of this technol¬ 
ogy. In fact, the strongest warning is: 


“Changes are still costly for ASIC in 
terms of money and perhaps in time. On 
the other hand, CAD tools reduce the 
need for change, since they produce 
simulation results that can be counted 
upon to predict circuit behavior, enabling 
a high probability of first-pass success.” 
It surprised me that the authors so blithely 
minimize the importance of time, since 
the greatest risk in using gate arrays is 
time lost in design iterations. The authors 
even make the related point that delays in 
bringing a product to market can result in 
major reductions in profitability. 

I was also surprised by the suggestion 
that simulation results can be counted on 
to provide a high probability of success. 

A simulation is only as good as the input; 
an ASIC can pass all the tests supplied by 
the user but still fail in the system because 
of unanticipated but valid conditions in 
the system. In fact, some vendors still 
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count among their customers who experi¬ 
ence “first pass success” those whose test 
vectors passed but whose systems did 
not. Glossing over this issue misleads 
those readers who have not been through 
the process for themselves. Adequate 
simulation is essential for ASIC success. 
The adequacy of the simulation rests 
solely on the quality of the test vectors. 
This point cannot be overemphasized. 

The individual parts stand quite well 
on their own, so those readers with previ¬ 
ous experiences in VLSI could read the 
parts or chapters of immediate interest. 
However, I believe that readers who are 
not already intimately involved in VLSI 
should read the book in the following or¬ 
der to avoid being overwhelmed by use¬ 
ful but distracting information. 

Begin with Chapter 1, which gives the 
editor’s objectives and the organization 
of the book, then go straight to Part 8 on 
VLSI economics. If your potential VLSI 
application does not pass this test, stop 
reading and spend your time in other pur¬ 
suits. Otherwise, go back to Chapters 2 
and 3 for very good discussions by Jerry 
DaBell and William Blood, Jr., of what a 
project manager becoming involved with 
VLSI devices will go through. 

In Chapter 4, author Vincent Coli of¬ 


fers one of the most welLwritten and con¬ 
cise descriptions of programmable logic 
devices I have seen. He discusses not only 
the evolution of these devices but also the 
strengths and weaknesses of the various 
architectures and the application areas in 
which they shine. This chapter would be 
invaluable to neophytes, since the same 
information from other sources is usually 
filled with vendor hype or is not written 
with this clarity and conciseness. Coli 
doesn’t cover application areas that 
could take advantage of field program¬ 
mable gate arrays, but since these devices 
were just starting to become popular 
when the chapter was written, this minor 
oversight is understandable. 

Project managers whose interest is still 
intact after these chapters should then 
have the nearest budding VLSI design 
engineer read (in this order) Chapters 17, 
18, 8-10, and 21-24. With the solid back¬ 
ground these chapters provide, custom¬ 
ers or other readers can than delve into the 
remaining topics in the order suggested 
by the editor. 

I enjoyed Edward Helper’s chapters 
(17 and 18) on hierarchical design and 
simulation. The design methodology 
flowchart could be put to good use in 
many organizations that take a less- 


disciplined approach. Helper’s emphasis 
on the benefits of simulation could save 
many from needless frustration and 
wasted effort on the test floor. 

Speaking of testing, with the increased 
interest in design for testability. Chapters 
8-10 should be of interest to a wide audi¬ 
ence. The topics — fault modeling and 
test generation, built-in self test, and 
automatic VLSI test equipment — are 
well covered. 

Packaging is also becoming critical in 
high-performance designs. The editor 
certainly keeps the customer’s perspec¬ 
tive in mind here by not shortchanging 
this vital topic with a cursory discussion. 
Author Daniel Amey provides a detailed 
description of the various packaging 
processes followed by a discussion of as¬ 
sorted packaging types and trends in re¬ 
sponse to VLSI requirements (Chapters 
23 and 24). 

All the authors are amazingly consis¬ 
tent. The editor seems to have brought out 
the best from a widely disparate group of 
contributors. This reference should be 
welcomed by those contemplating or in¬ 
volved in VLSI. 

Jack Hollins 

SOTA Technology 


NEW LITERATURE 


Al computers. As the power of artifi¬ 
cial intelligence algorithms and pro¬ 
grams grows, new architectural features, 
languages, algorithms, and representa¬ 
tion schemes are needed. Computers for 
Artificial Intelligence Processing 
(ISBN 0-471-84811-5, 600 pp., $54.95), 
edited by Benjamin W. Wah and C.V. 
Ramamoorthy, examines design issues 
and current research efforts for AI appli¬ 
cation support systems, including a spe¬ 
cial section on dtata parallelism and 
discussions of Lisp machines, and Small¬ 
talk-80 and VLSI systems. Contact John 
Wiley & Sons, 605 Third Ave., New 
York, NY 10158-0012. 

Guide to Common Lisp. In The Com¬ 
mon Lisp Companion (ISBN 0-471- 
50308-8, 480 pp., $27.95), Timothy 
Koschmann, a member of the ANSI com¬ 
mittee working on the Common Lisp 
standard, offers a guide to the draft stan¬ 
dard, including guidelines to Common 
Lisp object-oriented programming con¬ 
cepts and their relationships to existing 
Common Lisp methods, as well as exer¬ 
cises and solutions. Contact John Wiley 
& Sons, 605 Third Ave., New York, NY 
10158-0012. 


Updated text. In Inside the Computer 
(ISBN 0-7131-3588-3, 240 pp., $24.95), 
M.D. Cripps introduces the hardware as¬ 
pects of computer science including the 
design, construction, and operation of 
computer systems. The book, designed 
for students with a limited background in 
physics and electronics, is an updated and 
expanded version of Cripp’s previous In¬ 
troduction to Computer Hardware. Con¬ 
tact Routledge, Chapman, and Hall, 29 
W. 35th St., New York, NY 10001-2291, 
phone (212) 244-6412. 


Computer competitiveness. The Na¬ 
tional Research Council’s Computer Sci¬ 
ence and Technology Board has pub¬ 
lished the report of a recent colloquium 
on US competitiveness in the computer 
industry. Keeping the US Computer In¬ 
dustry Competitive: Defining the Agenda 
states that the US must exhibit better 
planning, leadership, and collective will 
“that cannot be attained with a business- 
as-usual approach by industry or govern¬ 
ment.” The $15 report is available from 
the National Academy Press, 2101 
Constitution Ave. NW, Washington, DC 
20418, phone (800) 624-6242. 


Supercomputing resource. Supercom¬ 
puting Systems, edited by Steven Karta¬ 
shev and Svetlana Kartashev, addresses 
software and hardware engineering and 
design, applications, algorithms, archi¬ 
tectures, components, and parallelism. 
The volume also covers such areas as 
mathematical theory and algorithms for 
multidimensional, multiparameter sys¬ 
tems; modeling and image processing for 
space science; and hypercube applica¬ 
tions for computationally intense prob¬ 
lems. The 656-page book costs $64.95. 
Contact Von Nostrand Reinhold, Mail 
Order Dept., P.O. Box 668, Florence, KY 
41022-0668, phone (606) 525-6600. 

C++ programming. Data Abstraction 
and Object-Oriented Programming in 
C++ (ISBN 0-471-92346-X, 450 pp., 
$34.95) by K.E. Gorlen, S.M. Orlow, and 
P.S. Plexico guides readers from tradi¬ 
tional program-design approaches 
through data abstraction, to object-ori¬ 
ented principles for creating modular, 
reusable software systems. The book de¬ 
scribes how to build class libraries in C++ 
and includes machine-readable ex¬ 
amples. Contact John Wiley & Sons, 605 
Third Ave., New York, NY 10158-0012. 
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Implementing Sparc in ECL, Emil W. Brown, 
Anant Agrawal, Trevor Creary, Michael F. 
Klein, David Murata, and Joseph Petolino 
Two companies successfully joined forces to 
design a small, low-cost system capable of large 
mainframe performance. 

Hot Chips and Soggy Software, Stephen C. 
Johnson 

RISC success springs partially from good sys¬ 
tem design. Take note and eliminate the system 
bottleneck from your new design. 

The i486 CPU: Executing Instructions in One 
Clock Cycle, John H. Crawford 
A cache integrated into the instruction pipeline 
lets this 386-compatible processor achieve 
minicomputer performance levels. 

Compiler Challenges with RISCs, Thomas J. 
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RISCs may possess simplified instruction sets, 
but don’t be fooled. Crafting their compilers is 
not so simple. 

Developing the GX Graphics Accelerator 
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In the first of a two-part series, the design team 
explains its total approach and the workings of 
the integer and floating-point units. 
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Silicon Chips, Meng-Hiot Lim and Yoshiyasu 
Takefuji 

Realizing fuzzy expert systems in VLSI circuitry. 

MIS/Finance Track — Inductive Learning 
for Risk Classification, Michael J. Shaw and 
James A. Gentry 

Incorrectly evaluating credit risks costs seri¬ 
ous money. 

Transfer Pricing: Integrating Expert Sys¬ 
tems in MIS Environments, Yehudah Freund- 
lich 

Turning a hard problem into a “trivial" expert 
system. 
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Developing a generic system that most publish- 
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Test Technology in Europe, Ben Bennetts 
A review of technical developments at the first 
European Test Conference. 

Designing and Implementing an Architec¬ 
ture with Boundary Scan, R.P. Van Riessen, 
H.G. Kerkhoff, and A. Kloppenburg 
This hierarchical, testable architecture, which 
is compatible with the JTAG boundary scan 
standard, allows a macro self-test to be initial¬ 
ized, controlled, and verified from the IC to the 
printed-circuit board level. 

Contactless High-Speed Waveform Meas¬ 
urements on Gallium Arsenide ICs, H.K. 


Seitz, A. Blacha, R. Clauberg, H. Beha, and J. 
Feder 

Photoemission sampling compares favorably 
with results from electron-beam probing, par¬ 
ticularly in terms of measurement time. The sys¬ 
tem described here can also activate devices 
within a chip by a pulsed, visible light beam. 

Test Generation for Current Testing, Phil 
Nigh and Wojciech Maly 
Current testing can detect many manufacturing 
faults in CMOS ICs that stuck-at fault testing 
misses. Test-generation methods traditionally 
used for stuck-at faults are not suitable, how¬ 
ever, and the authors suggest a different method 
in which realistic fault methods are extracted 
from the circuit layout. 

Using a Test-Specification Format in Auto¬ 
matic Test-Program Generation, Bas Verhelst 

Testing would be much easier if we could keep 
and transfer the necessary information in a 
standardized format. Information such as tim¬ 
ing and patterns and electrical and environ¬ 
mental data could follow the product from con¬ 
ception to field use. 

The Challenges of Self-Test, In this informal 
panel discussion, testability experts deal 
frankly with the obstacles to industry-wide use 
of self-test. 

A D&T Roundtable — Behavioral Descrip¬ 
tion Languages, Part 1: Are Designers 
Benefitting? This part of a two-part roundtable 
explores designers’ attitudes toward the grow¬ 
ing popularity of high-level description lan¬ 
guages. In part two, next issue, participants 
from US companies that endorse VHDL, and 
representatives from Japanese companies that 
are standardizing on UDLI face off. 
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“Any clod can have the facts, but having opinions is an art.” 

Charles McCabe, San Francisco Chronicle 


THE 


CHANNEL 


Protect or license: It’s Apple’s choice 

Skillman Cannon Hunter, Acropolis Software 


Joseph Arceneaux challenged that now 
is the time for programmers to “make 
themselves heard” regarding copyright 
protection for user interfaces and, in par¬ 
ticular, Apple Computer’s Macintosh in¬ 
terface [Open Channel, Dec. 1989, p. 72], 
I strongly oppose Arceneaux’s stand that 
user interfaces should be free for all to use. 

Arceneaux cites a previous analogy to 
the automobile interface. The analogy is 
a good one, but his use of it is not fair. The 
automobile interface did not pop out of 
the blue, ready for use on all cars. Its evo¬ 
lution took years and numerous patents, 
which gave the inventors a period of pro¬ 
tection and the right to collect royalties as 
compensation for their contributions. I 
am sure many of the inventors made their 
fortunes from portions of the interface we 
now take for granted. 

All patents expire after 17 years. They 


do not preserve forever the inventor’s 
right to prevent competition by refusing 
to license the invention. Copyrights, on 
the other hand, last forever and were 
originally intended to prevent someone 
from duplicating a creative work in toto 
and selling it without a license. If a work 
is not duplicated in toto, then the lawyers 
have their fun and games. Historically, 
our patent system has pertained to hard¬ 
ware, while software has been in the pur¬ 
view of the copyright system. Of course, 
this demarcation has been blurred since 
the early 1980s, when patent protection 
became available for software. 

Arceneaux indicates that Apple didn’t 
invent the graphic interface, as Lotus 
didn’t invent Visicalc. If Apple indeed 
stole the Star interface, it is up to Xerox to 
protect its right. Lotus bought Visicalc. 
Can we maintain that neither Apple nor 


Lotus should be afforded rights to what 
they claim to own? 

The situation is clear. Apple made a tre¬ 
mendous advancement in the art of com¬ 
puting — the greatest leap I’ve seen in 30 
years. The magic of the Macintosh 
dawned on me the first day I used Claris’ 
Filemaker — the only software product I 
have used daily for four years. Also, Mac¬ 
intosh compilers have taken my program¬ 
ming productivity and satisfaction light 
years ahead of where it was. Apple is to be 
amply rewarded for making the Macin¬ 
tosh a commercial success. Anyone who 
wants me to program a different computer 
will have to offer a better environment. 

Apple can keep its interface for itself or 
license it. It’s Apple’s choice; don’t ask 
me to defend any attempt to circumvent 
it. Creative people will find ways to build 
on Apple’s contribution. 


Variations on a previous theme 


Michael Robinson, KLA Instruments 

Will Tracz states there is an “uncanny 
parallel” between the skills needed by 
musicians and software developers 
[Open Channel, Jan. 1990, p. 72]. Of 
course, there are certain similarities 
(both frequently use keyboards), but 
there are differences as well. For ex¬ 
ample, musicians sometimes use com¬ 
puters as tools when composing music, 
but software developers never use musi¬ 
cal instruments as tools when writing 
software. Also, musical instruments have 
a standard computer interface (MIDI), 
but computers don’t have a standard mu¬ 
sical interface (although I have heard that 
for certain computers built in the 1950s, 
infinite loops could be detected by listen¬ 
ing to a radio placed next to the CPU). 

Tracz’ suggestion did, however, 
prompt me to draw from my own experi¬ 
ence certain characteristics of a musical 
career that he neglected to mention. 
Whether or not these have analogies in 


software development I leave to the 
reader; 

• Public performance of music always 
takes place in real time with no opportu¬ 
nity to correct errors. (In recording stu¬ 
dios, errors can be corrected afterward.) 

• The way a piece of music is per¬ 
formed is often radically different from 
the way it is specified (the written music), 
and the mapping from specification to 
performance can only be done success¬ 
fully by someone intimately familiar 
with the application area (musical style). 

• To make a living, musicians are fre¬ 
quently forced to perform music they de¬ 
test and know to be artistically valueless. 

• Financial rewards are considerably 
greater in the fields of advertising 
jingles, Muzak, and commercial pop than 
in fields requiring more creativity from 
the artist. 

• Success in the music business is fre¬ 


quently due more to image and hype than 
to musical ability. 

• Success in the music business is usu¬ 
ally judged by sales volume rather than by 
creativity or performing ability. 

• An attempt to develop a personal 
style, create a new style, or otherwise pro¬ 
duce music that differs in any way from 
that which the music industry is already 
producing is usually met with derision 
and hostility. 

• Professional performers typically 
devote several hours a day to unpaid prac¬ 
tice. 

• Since the introduction of the phono¬ 
graph and sound movies, the employment 
of musicians has fallen steadily due to 
competition from mass-produced repli¬ 
cations of previously recorded perform¬ 
ances. 

• The average income of a professional 
musician in the US is less than $5,000 per 
year. 
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Chips Symposium 


Santa Clara University, Santa Clara, California 
Monday &; Tuesday, August 20-21, 1990 


General Chair: Hasan AlKhatib, Santa Clara University 
Program Co-chairs: Alan Jay Smith, UC Berkeley & John Crawford, Intel Corp. 
Program Committee: Forest Baskett, Dave Ditzel, John Hennessy, Dave Patterson, , and 

Mario Tokoro 


Call for Contributions 

Hot Chips is back. Sponsored by the IEEE Computer Society Technical Committee on 
Minicomputers and Microcomputers Hot Chips - 2 is a conference that consists of presen¬ 
tations on high performance chip and chip-set products, and related topics. This conference is 
directed particularly at new and exciting products. The emphasis is on real products, not aca¬ 
demic designs. Participants will not be required to prepare written papers. The proceedings 
will consist of copies of the slides to be presented. 

Contributions are solicited in the following areas: 

• RISC and CISC Processors 

• Floating Point Processors 

• Embedded CPUs 

• Graphics and Image Processing Chips 

• Digital Signal Processors 

• Network Chip Sets 

• Bus Chips 

• Cache Controllers and Memories 

• Neural Chips 

• Systolic Array Chips 

• Compiler Issues with Hot Chips 

• Benchmarking and Performance Evaluation 

Proposals should consist of a title, a one paragraph description of the product or topic to 
be presented, and the name, title, address, phone number, fax number, and electronic mail 
address of the presenter. If this is a not yet announced product, and you would like the 
submission kept confidential, please indicate it; we will do our best to maintain confidentiality. 
Submissions by April 1, 1990 should be sent to: 

Prof. Alan Jay Smith, Computer Science Division, EECS Department, University of 
California, Berkeley, CA 94720, USA, or John Crawford, Intel Corporation, SC4-59, 2625 
Walsh Avenue, Santa Clara, CA 95051, USA 

For further information about the symposium, contact Hasan AlKhatib at (408)554-4485 or 
at halkhatib@scu.edu. 
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"Untrammeled nature expressing itself...in an unpredictable 
brain... But who could handle such a thing? It was a hydra, 
merciless and uncontrollable.. . James Gleick 


e old adage that “the human 
brain is too vast and complex to be 
understood even by itself” is un¬ 
der direct assault on several fronts 
by techniques we know collectively 
as neural computing. 

If we can learn how the seeming 
cacophony ofvoices and structures 
that comprise the human cortex 
can forge order from chaos, then 
perhaps we can “reverse-engineer” 
the brain. Perhaps we can build 
systems that mimic the brain’s 
processes and put them into com¬ 
puters. Perhaps we can automate 
reasoning. 

One approach is studying the 
trajectories of data sets generated 
by EEG waves. When plotted in 
multiple dimensions as computer 
graphics, extraordinary yet non¬ 
periodic, “spatially coherent” pat¬ 


terns begin to emerge. These 
shapes may be the result of ran¬ 
dom events - i.e., the white noise 
of EEG activity - being tugged at 
by something that has a purpose, 
perhaps even an “intelligence,” all 
its own. “Strange attractors” may 
be at work. 

Strange attractors are just one 
of the novel phenomena that will 
be discussed at the 1990 Interna¬ 
tional Joint Conference on Neural 
Networks (IJCNN), .Tune 17- 21. 

in San Diego, California. 

IJCNN ’90 will cover the full 
spectrum of neurocomputing, 
from theoretical neuro-dynamics 
to more pragmatic machine vision 
applications. Hear and meet the 
leading experts and experimental 
pioneers during the largest con¬ 
ference in the field. 



Image shows the EEG trace from a mammal during an epileptic seizure. Research 
from Dr. Walter Freeman, Co-Chair, Programsfor IJCNN ’90. Better understanding 
of the brain is leading to more useful machines. 


• Plenary Speaker: James Burke, 
creator and host of the popular PBS 
TV programs “Connections” and 
“The Day the Universe Changed.” 

• Technical Sessions: 16 sessions 
reporting the latest advances in 
neural network theory, neurocom¬ 
puting hardware and applications. 

• Tutorials: Experts from acade¬ 
mia and industry will present 14 
topics in tutorials preceding the 
conference. Timely information to 
those most closely concerned with 
neural network applications. 



IJCNN is an in¬ 
ternational forum 
devoted to the 
science and tech¬ 
nology of neuro¬ 
computing in in¬ 
dustry, academia 
and government. 


• Exhibits: See the latest advance¬ 
ments in neurocomputers, neuro¬ 
software and applications develop¬ 
ment. 

• Poster Sessions: Presented 
twice a day with authors present. 


For li'r'dcllSre and registration 
information, call (619) 453-6222 or 
write to Nomi Feldman, IJCNN, ^ v 
5665 0berlin Drive, Suite 110, San 
Diego, CA 92121. Substantial sav¬ 
ings realized for early registrati on-. 
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